Receiver: ts-proto generated codec replaces the hand-rolled reader/writer

[lannbot]

What

Replaces receiver/src/proto.ts (hand-rolled protobuf Reader/Writer) and the per-op tag switch in frames.ts with ts-proto generated readers and writers over @bufbuild/protobuf/wire. Event payload encoding uses the generated writer too. No hand-written wire code remains in the receiver.

Why

docs/design.md said the JS codec was pbf; it never was — the hand-rolled codec was chosen silently in a dispatch and the record was not updated. Evaluating the options against the receiver's actual needs:

• pbf (the documented choice): readSVarint is silently wrong above 2^53 (2^53+1 → 2^53), no bounds checks (a truncated string clamps silently), and its generated readers cannot represent proto3 optional presence — the schema uses that for ns/parent/anchor, and real streams contain InsertBefore.parent = 0.
• protobuf.js 8: exact int64, bounds-checked, but generated readers are 4x slower than the hand-rolled decoder and the runtime is +20 KB gzipped.
• ts-proto 2 + @bufbuild/protobuf/wire: exact sint64 (forceLong=number throws on unsafe values), bounds-checked, optional → undefined, +3–4 KB gzipped.

Measured over the bench producers' real captured streams (19, every op) into the same FrameSink (harness kept untracked under bench/decoders/; three runs, geomean stable to ±0.04):

arm	time vs hand-rolled
ts-proto generated	0.67–0.71x
ts-proto hand-driven hybrid	0.73–0.78x
protobuf.js hybrid	0.64–0.68x
protobuf.js generated	4.1–4.3x
pbf (either)	~0.58x, disqualified above

The hand-rolled decoder loses on allocation (two Readers, a tuple per tag, a closure per frame), not on the wire format. Generated readers everywhere is both fastest-correct and the least hand-written code; the live receiver after this PR measures ~0.8x the old decoder's time on the same harness (with unknownFields=true for strict mode).

Codegen

buf from npm runs under Deno and spawns the ts-proto plugin through deno run — no Node, no protoc (buf.yaml, buf.gen.yaml, just proto-ts). receiver/src/gen/*.ts is committed; just check regenerates into a temp dir and diffs (just proto-drift). The unanchored gen/ .gitignore rule (for host/desktop/gen) is anchored so the generated code can be tracked.

Semantics preserved / changed

• FrameSink and its exported types are unchanged.
• Framing: partial-frame buffering across push, MAX_FRAME_BYTES, truncated length prefix = wait vs malformed = error (5-byte u32 bound, now tested at frame level).
• Each frame is bounded by a post-decode position check on the shared reader: a nested length that overruns the frame, or a decode that stops early on a zero/end-group tag, is a malformed frame in both modes (regression tests added; the previous decoder threw on the first, tolerated a zero tag with wire type 0 by accident).
• Strict mode walks _unknownFields with the same unknown field N in <Message> errors.
• SetProperty.int outside Number.isSafeInteger now throws instead of silently losing bits.
• Event payload bytes omit proto3 zero defaults the hand writer used to emit; decoded values identical.

Gates

just check (incl. drift gate), deno task test (128), deno fmt --check, cargo test -p stream-dom-guest, just site, just e2e, just bench-wire (byte-identical wire shapes — the encoder side is Rust). Equivalence gate: the live decoder's sink-call trace is identical to a frozen copy of the old decoder over all 19 corpus streams. Independent review: one blocking finding (per-frame bound lost with the shared reader), fixed with tests.

deno lint receiver has one pre-existing failure in policy-desktop.ts:476 (no-control-regex), untouched here.

Automerge armed (merge commit).