uci: bound net_poll's copy by the request; $8A is UDP-only, $8B breadcrumb (#140)

[JC-000]

DRAFT until #142 merges — this branch pins a snapshot of #142; if #142 is amended in review, this branch must be rebased before merge (merging it first would land both commits under this title and leave #142 empty). After #142 merges, check with git merge-base --is-ancestor origin/fix/140-socket-read-header-bound origin/master once this one merges too.

Closes #140. Stacked on #142 (same file) — merge #142 first.

What the measurements said

Porting c64-wireguard's drop-on-over-claim check verbatim aborted every real github.com handshake at the first read (2/2). With the request/claim pair added to the rig's post-mortem dump:

poll	uci_req_len	uci_read_hdr
first (idle poll — ClientHello sent, ServerHello not yet arrived)	$0200	$FFFF
last (22 B queued)	$0016	$0016

Correction (same evening): $FFFF is the firmware's no-data sentinel on both transports — c64-wireguard measured every idle UDP poll returning it (11/11 sizes), and tls_last_state=2 means our first-poll capture was an idle poll waiting for ServerHello ("~690 B queued" was an inference). The drop-and-error cut aborted on an empty read; c64-wireguard had carried the same misfiling for four days as a documented firmware quirk. $FFFF must be excluded before any over-claim test. The code here already does the right thing (cap, then the DATA_AV check copies zero bytes) — commit cfebf5f corrects the comments only, PRG byte-identical.

What lands

• Bound, not error: uci_poll_rem = min(header, uci_req_len). Bytes beyond the request were never delivered and stay queued for the next poll, so nothing is lost; the copy can no longer run away on a bogus header regardless of what the per-byte checks do.
• $8A UCI_ERR_LONG_READ keeps c64-wireguard's datagram disposition (excess discarded by firmware → datagram unrecoverable → dropped) and is never emitted on TCP. Registry row reworded by disposition in c64-lib-contract#139.
• $8B UCI_ERR_BAD_READ_HDR (new): header above the request that is not the $FFFF no-data sentinel — a value the firmware has no documented mode for; the stream-family counterpart of $8A (datagram: drop). Best-effort breadcrumb on the §13.1 short-write pattern: C=0, copy still capped, code left in net_last_error for post-mortems. Allocated in SPEC §13.2's table before the adapter emits it — the first code through the rule the table exists for.
• Rigs: _dump_diag prints uci_req_len / uci_read_hdr.

Evidence

• Cap-only build (eccb7ec7…): U64E 48 MHz, rig_https_live github.com PASS, HTTP 200, CFIN 48.5 s.
• Cap + $8B build (2396d97d…): $88 NO_SOCKET at TCP_CONNECT, 2/2, tls_last_state=0, uci_req_len=$0000 — the socket never opened, so net_poll never ran. This is the device's after-N-loads connect degradation (~14 loads today; c64-wireguard measured P P P P P T T T on unmodified master), not the change, which is unreachable without a socket. The twelve added bytes are hardware-unverified today; a power cycle and one run will close that. Both builds link clean, no warnings.
• The first-cut drop-and-error build (a6d2d3b1…) is the negative control: it FAILs with $8A at tls_last_state=2 every time.

🤖 Generated with Claude Code