Add focused fuzzing for parser and protocol boundaries

[PierrunoYT]

Proposal

The repository has extensive deterministic Go tests but no func Fuzz* targets at audited main revision 1b5db1765672820caac1684b168c9898b5ba3593. This is not a coverage-percentage complaint and should not become a mandate to fuzz every package.

The proposal is to add a small, evidence-driven fuzzing tier for parser and protocol boundaries where malformed byte sequences have meaningful security or reliability consequences.

Candidate order

1. Release checksum parser — arbitrary lines, duplicate records, filenames, casing, and malformed digest lengths; invariant: never panic, accept exactly the documented one-record grammar, preserve filename attribution checks.
2. Archive entry/path normalization — mixed separators, absolute/drive/UNC/device forms, dot components, invalid UTF-8; invariant: no accepted entry escapes the intended lexical/rooted policy. Native Windows regression cases remain necessary because fuzzing on Linux does not emulate reparse semantics.
3. Daemon/ACP/MCP framing and JSON decoding — truncated headers, length extremes, invalid JSON/UTF-8, repeated/unknown fields; invariant: bounded allocation, no panic/hang, complete-write/read errors remain explicit.
4. Credential redaction normalization — NUL/ESC/C1-split credentials and malformed control sequences; invariant: normalize before matching, never reassemble a secret on output.
5. Stream/provider event parsing — arbitrary chunk boundaries and partial terminal records; invariant: no panic, bounded buffering, stable error classification.

Guardrails

• Every discovered defect gets a deterministic regression test; the fuzz target is not the only evidence.
• Seed corpora come from existing valid fixtures and known boundary cases.
• Keep short deterministic fuzz smoke runs in CI; longer campaigns can be scheduled separately.
• Set explicit size limits so CI cannot be exhausted by generated inputs.
• Do not use Linux fuzz success as proof of macOS/Windows path safety.
• Do not replace race, native-platform, release, or smoke gates.

Questions

• Which two boundaries should be the initial pilot?
• Should short fuzz smoke tests run on every PR or in a scheduled job with uploaded corpora?
• Where should corpus artifacts live, and what review policy should apply to promoted crashers?
• What runtime budget is acceptable given the existing full/race suite duration?

Audit context: finding TEST-03.

Full testing audit: https://github.com/PierrunoYT/zero/blob/audit/codebase-audit-2026-09-08/docs/audit/TESTING_AUDIT.md#test-03--no-fuzzing