boot.s HTTPS demo path copies only the first decrypted TLS record into http_resp_buf — body never displayed #72

Found during the hardware-free e2e work (PR #71, commit 24abf3e).

The 'G' (HTTPS GET) demo path in src/boot.s copies only the FIRST
decrypted TLS record into http_resp_buf (158 B = status line + headers in
the local-listener setup). When the response body arrives as a second TLS
record — which it does whenever the server flushes headers and body
separately — the body is received, decrypted, and ACKed but never copied,
so the on-screen demo shows headers only.

Pre-existing behavior, NOT a regression: the http_get path proper has the
real body semantics (Content-Length-terminated, validated on UCI e2e); this
is specific to the boot.s demo flow. tests/test_vice_https_macos.py
asserts the demo contract (200 status line in the raw buffer) and reports
body-in-buffer informationally.

Fix sketch: keep copying until http_content_length is satisfied (the
Content-Length machinery already exists in http.s), or route the demo
through http_get instead of its own copy loop.

Related (same investigation, separate concern): tcp_recv_overflow=1 was
observed after TCP retransmission bursts despite a total flight far below
the 4 KB ring — stream integrity held (dup segments legitimately re-enter
the ring), but the flag's semantics ("overflow" vs "duplicate-drop") may be
worth sharpening before anyone alarms on it.

🤖 Generated with Claude Code