test: add fuzz harnesses for Meshtastic codec and protocol parsing

[forkwright]

Problem

kerykeion's Meshtastic codec parses binary protocol frames from untrusted radio input. The codec has good unit tests for malformed input rejection, but no fuzz testing to discover edge cases that hand-written tests miss.

Required

1. fuzz/ directory with cargo-fuzz targets
2. Targets for: Meshtastic frame decoding (codec.rs), protobuf-like message parsing, mesh packet routing decisions
3. Seed corpus from the existing test fixtures
4. Property tests (proptest) for codec round-trips: arbitrary valid frame → encode → decode → equals original

Impact

Radio protocol parsing handles untrusted input from the mesh network. A parsing bug could crash the collector or corrupt state.

[forkwright]

Property tests shipped in 39b765c: 6 proptest cases (codec round-trips, arbitrary byte resilience, partial frame handling, ID serialization). 182 kerykeion tests passing.

[forkwright]

Reopening after a clause-level acceptance audit against exact main@ffa416fc.

Only required item 4 landed: the closing comment itself cites six proptest cases. Required items 1-3 are still absent: the tree has no fuzz/ directory, no cargo-fuzz targets for frame decoding/message parsing/routing decisions, and no seed corpus derived from fixtures. A full-tree path search confirms those surfaces do not exist.

Keep the property tests as accepted partial work. Close only after the three fuzz targets and their seed corpus exist, are exercised by an appropriate CI/manual fuzz-smoke mechanism, and the existing round-trip properties remain green.

[forkwright]

This issue was closed by accident, and it should stay closed. Both halves of that need saying, because
a closure whose stated reason is "an automation misread a sentence" is worth exactly nothing to the
next reader.

The accident. PR #428's body contained the sentence "This does not close #95", under a heading
explaining why the PR deliberately stopped short of claiming the issue. GitHub's closing-keyword parser
does not understand negation: it matched close #95 inside that sentence and closed the issue on
merge. The disclaimer performed the act it disclaimed.

Why it stays closed anyway. The reopening comment's condition was that the three fuzz targets and
their seed corpus exist, are exercised by an appropriate CI or manual fuzz-smoke mechanism, and the
existing round-trip properties remain green. Verified against origin/main:

• fuzz/fuzz_targets/ holds three targets — frame_decode, message_parse, routing_decision —
  covering frame decoding, protobuf message parsing, and routing decisions, which are the three the
  issue named.
• fuzz/corpus/ holds twenty seeds, derived from the frame layout documented in codec.rs and from
  protobuf wire encoding, each named for the shape it exercises.
• .github/workflows/fuzz.yml runs each target for sixty seconds on changes to fuzz/** or
  crates/kerykeion/**, weekly, and on demand. It is not decoration: it has run four times since
  merging and has both passed and failed on real conditions.
• The proptest round-trips from 39b765c are untouched and still green.

So the Done condition holds on its merits. This comment is the justification the accidental closure did
not supply.

One thing the fuzzing already found, which is the best evidence the harness works. Within sixty
seconds of first running, message_parse failed — on a defect in its own assertion rather than in the
parser. It compared decoded values across a re-encode, and these messages carry f32 fields where
NaN != NaN, so a byte-perfect round trip of a NodeInfo.snr of NaN was reported as a failure. The
assertion now compares encoded bytes, and the reproducer is kept as corpus/message_parse/nan_snr.bin.

Worth carrying forward for anyone writing a careful PR body: a negated closing keyword still
closes. "does not close #N", "this should not fix #N", and similar all trip the parser. Write the
number without the keyword — "#N stays open" — or the sentence disclaiming the closure will cause it.