fix(http): span-input parser — demo path shows the body, TLS plaintext never enters the ciphertext ring

[JC-000]

Closes#72.

The reported bug

The 'G' HTTPS demo in boot.s hand-rolled its response receive: one
net_poll/tls_recv iteration, then a single-page copy of that first
decrypted record into http_resp_buf (the "up to 512 bytes" comment was also
wrong — the loop caps at 256). Whenever the body arrived as a second TLS
record it was received and ACKed but never copied, so the demo displayed
headers only.

The deeper flaw it exposed

Routing the demo through the production parser surfaced a pre-existing problem
in http_get's own TLS path: it fed decrypted plaintext back into the shared
TCP ring (tcp_recv_tail) and parsed from there via net_recv_byte. That
ring is the ciphertext queue. On ip65 the rx callback queues eagerly, so
ciphertext for later records (body record #2, the peer's close_notify) is
typically already sitting between head and tail — the parser then reads
ciphertext as HTTP text (garbage status) or loses the body. UCI masked it
because its adapter reads on demand.

Fix — dual-source parser input (http_in_byte)

mode	input	used by
0	TCP ring (delegates to net_recv_byte)	plain HTTP — the ring legitimately holds plaintext there
1	current decrypted record as a linear span (http_in_ptr/http_in_len, 16-bit)	TLS

The ring stays pure ciphertext on the TLS path: no feed, no discard, and
multi-record bodies parse correctly on both backends. The span path also drops
the old feed loop's "TLS records < 256" assumption (it honored only
tls_app_len's low byte). http_in_byte preserves X/Y to match
net_recv_byte's contract and uses SMC rather than zp_ptr, which the parser's
body-store state owns.

The receive/parse loop is extracted as http_recv_body, shared by http_get
and the demo, so there is one implementation of the response semantics. Mode is
set per TLS record and reset to 0 in the plain path's parser init, so
alternating 'H' and 'G' in one session is safe.

Also (comment-only): tcp_recv_overflow semantics documented at its
declaration and set site — retransmission duplicates enter the ring too, so the
flag can latch during retransmit bursts with in-flight data far below ring size
(observed: 690 B flight, stream intact). It is a diagnostic breadcrumb, not
proof of loss — but ip65 ACKs the full inbound length regardless of what the
callback copies, so a dropped tail that was new in-sequence data is genuinely
gone. No accounting redesign here.

User-visible: the 'G' demo now prints the response body instead of
status line + headers. Shared code, so this applies to UCI too.

Validation

test	result
all five link profiles	pass, sizes unchanged (47,105 / 62,977 B)
tools/test_http.py (VICE, mode-0 ring path incl. 120 B body + 404)	27/27
ip65 REU e2e (VICE)	PASS — http_status=200, resp_len=22, body match
ip65 REU-less onchip e2e (VICE, no -reu)	PASS — 1,813.9 s, http_status=200, resp_len=22, body match
C64 Ultimate hardware, UCI onchip @48 MHz (mode 1 / TLS)	PASS — 200, body HELLO FROM TLS SERVER; ring verified pure ciphertext (16 03 03…, 17 03 03…) with head==tail
C64 Ultimate hardware, plain HTTP @64 MHz (mode 0 / ring)	PASS — 200, full 22 B body through http_recv_body

Both parser input modes are confirmed on real hardware, and both VICE screens
now end with the body text (TLS13 OK FROM C64 TEST) where they previously
showed headers.

🤖 Generated with Claude Code