fix(messages): derive the declared payload length when encoding a message

[JustinKovacich]

Stacked on #16 — merge order: #11 → #12 → #13 → #16 → this.

Issue URL

Closes #15.

What

Message::encode could emit a frame that Message::decode rejects.

decode takes exactly header.payload_length bytes and hands them to
Payload::decode, which is not required to consume all of them. The decoded
Message keeps the header verbatim, declared length included, and encode
wrote that stale field beside a payload of its real size. Note that
encoded_size() already disagreed with the header being written — it returns
Header::SIZE + payload.encoded_size(), not the declared length.

// A NACK body is one byte. This header claims five.
let framed = [0x02, 0xFD, 0, 0, 0, 0, 0, 0x05, 0x03, 0, 0, 0, 0];
let (msg, _) = Message::decode(&framed).unwrap();   // accepted
assert_eq!(msg.header.payload_length, 5);           // preserved
// re-encode -> 9 bytes, header still claims 5
Message::decode(&encode(&msg));  // Err(Incomplete { needed: 5, available: 1 })

Anything that decodes a frame and re-emits it — a proxy, a replay tool, a
logging fake, a test harness echoing what it received — was turning a
malformed-but-accepted frame into a corrupt one on the wire. This crate's own
MessageCodec encoder is on that path.

The fix

encode builds its header from payload.encoded_size() rather than trusting
self.header.payload_length, so an encoded frame is always self-consistent
regardless of how lenient decode is. No input that is accepted today starts
being rejected.

The consequence, documented on the method: for a frame that arrived with a
mismatched declared length, decode(encode(m)).header.payload_length is the
payload's real size rather than the length it arrived with. That is the point —
but it is a visible behavior change, so it's in the changelog.

A well-formed frame is byte-identical, which is why all 11 golden vectors
still pass unchanged. That's also pinned as a test.

MessageError::PayloadTooLarge covers the one fallible step — a payload too
large for the u32 length field, unreachable for a frame off the wire whose
length was itself a u32. MessageError is #[non_exhaustive], so adding it
breaks nothing.

Why not make decode strict instead

That is the standards-correct complement — ISO 13400-2 has an entity answer an
invalid payload length with NACK 0x04, and MessageError::PayloadLengthTooShort
sits unused for exactly this. But it's a redesign, not a fix: Payload::decode
would have to report unconsumed bytes, and the identification requests
deliberately discard their EID/VIN body (ARCHITECTURE.md §7.6), so a
0x0002 request carrying its six EID bytes would start being rejected outright
rather than declined — breaking the UDP responder path.

Recorded in ARCHITECTURE.md §7.6 as deferred rather than dropped.

Testing

tests/encode_consistency.rs	3 regression cases: overlong length on a fixed payload, nonzero length on a unit payload, and a well-formed frame encoding to the bytes it came from
golden vectors	11/11 pass unchanged — the fix cannot touch a frame whose declared length was already right
fuzz_roundtrip, skip removed, idempotence asserted	21,033,263 executions clean
other three fuzz targets	6.4M / 8.1M / 1.7M clean
full test suite, all features and none	pass
clippy --all-targets --all-features -Dclippy::pedantic, and --no-default-features	clean
cargo doc with -D warnings, cargo fmt, pre-commit, cargo publish --dry-run, MSRV 1.88	pass

The fuzz target now asserts payload and payload-type equality plus
idempotence (encode, decode, encode again → identical bytes) rather than
whole-Message equality. Asserting full equality would assert the bug back
into existence, since the declared length legitimately normalizes; idempotence
buys back the field-order asymmetry detection that equality was providing.

Also

Corrects PayloadLengthTooShort's message, which read "does match" where it
meant "does not match" — a user-visible error string.

Release bump: 0.6.0

This PR sits at the top of the stack, so it also carries
chore(release): v0.6.0 — the version the whole stack (#11 → #17) publishes
as. It follows the same pattern as 0.5.2, whose bump was made inside #10's
branch rather than by cargo release on main.

Nothing in the stack breaks a signature: MessageError is
#[non_exhaustive], so PayloadTooLarge is additive, and
ClientConnectionInfo::logical_address keeps its type and only starts
carrying a real value. The bump is for the encode change in this PR — a
caller that set a mismatched payload_length deliberately (a negative-test
fake, a corpus generator, a proxy replaying what it saw) stops being able to
emit that frame, with no compiler diagnostic anywhere. The CHANGELOG entry is
marked Breaking: so the version and the section header tell the same
story.

v0.5.2 is now tagged at the #10 merge on main (304d014), so that
section has a comparison range and the release links run
v0.5.2...v0.6.0.

Review status

Not reviewed by anyone yet. Draft.