fix: address 5 audit findings (receipt binding, pin handling, strict DoS bound, CI pinning)

[EulBite]

Summary

Five reported findings, each verified by a concrete reproduction before fixing. None change canonical output or the demo WAL chain root, so existing signatures and cross-language vectors still verify.

Findings and fixes (in priority order)

F1 - Receipts not bound to their entry (high)

A genuine, validly signed server receipt issued for event A verified Ok when copied verbatim onto a different entry B, because verify_receipt_signature only checked the receipt's own signed fields and never compared them to the entry. The receipt is also outside the chain hash, so the staple was undetectable. This defeated the receipt layer's "the server attested to THIS event" guarantee.

Fix: after the signature check, bind the receipt to the entry (payload_hash, plus event_id when the entry declares one). A mismatch is ReceiptError::EntryMismatch, surfaced by the lenient verifier as receipt_entry_mismatch (so valid becomes false). The module doc, which previously overstated the protection, is corrected.

F3 - Malformed --trusted-pubkey failed open (medium)

A fat-fingered pin made the lenient core warn and silently fall back to record-declared keys, returning valid=true / exit 0. The strict path already rejected the same input.

Fix: the CLI validates the pin (64 hex, 32 bytes, optional 0x) up front and returns a usage error (exit 2) on a malformed value, consistent with strict.

F2 - Pin did not require records to be signed (low)

With a pin set, the lenient verifier still accepted unsigned (None, None) records, contradicting the --trusted-pubkey help text ("MUST have signed every record").

Fix: when a pin is set, an unsigned record is flagged as unsigned_record. The help text is corrected to describe the exact behavior (and notes that --strict is the all-signed profile).

F4 - Strict DoS caps applied after parse (low)

MAX_RECORDS_DEMO / MAX_PAYLOAD_BYTES only bounded the result of parsing: a single oversized line was fully parsed (and its payload canonicalized) before the payload cap could reject it.

Fix: a new public MAX_LINE_BYTES (16x the payload cap) is checked before parsing each line, rejecting an oversized line as LineTooLarge without parsing it. The MAX_PAYLOAD_BYTES doc no longer claims to bound parse cost.

F5 - CI installed wasm-pack via curl | sh (low)

Both jobs piped a live, version-unpinned remote script into sh.

Fix: cargo install wasm-pack --locked --version 0.14.0, a reproducible checksummed install from crates.io (verified it compiles cleanly).

Tests and verification

• New regression tests: receipt entry-binding (match, payload_hash mismatch, event_id mismatch), pinned-unsigned rejection, malformed-pin usage error, oversized-line rejection.
• cargo fmt --all --check clean; cargo clippy --workspace --all-targets -- -D warnings clean.
• cargo test --workspace --all-features: all pass (97 core, 22 CLI smoke, 7 cross-language vectors, 4 parity, 3 wasm).
• wasm-pack build, demo-seeder, and the Node integration test all pass; demo chain root unchanged.