agent+rack: fix multi-packet recv loss; pod-side fastboot client

[widgetii]

Summary

Two fixes that together make the SPL+agent path actually work over the rack pod's WiFi-bridged UART. The first is a regression-class bug in agent.protocol; the second is the host counterpart to a new POST /fastboot endpoint on the rack pod.

---

1. agent.protocol.recv_packet — async path was losing post-delimiter bytes

The pyserial path through _recv_packet_sync already maintained a per-port leftover buffer for bytes that arrived in the same read as a frame's delimiter but after it (those bytes belong to the NEXT frame). The async path was written without one. When a chunk contained two whole packets back-to-back — e.g. RSP_DATA + 0x00 + RSP_ACK + 0x00 — the for-loop returned the first frame and silently discarded the rest.

Result: only single-packet commands worked on async transports (SocketTransport, MockTransport). INFO and CRC32 worked (one packet); READ and the streaming WRITE responses timed out 100% of the time because the trailing RSP_ACK was already consumed from the socket and gone.

read 16 bytes at 0x40010000 (RAM)... FAIL: TimeoutError
read 16 bytes at 0x14000000 (FLASH)... FAIL: TimeoutError

Fix: a transport-keyed _async_leftover buffer that's drained before each socket read and refilled with any bytes that came after the parsed frame's delimiter. Same semantics as the pyserial buffer, just keyed on id(transport) to avoid coupling Transport to the parser.

Post-fix, same hardware:

read 16 bytes at 0x40010000 (RAM-16)...    OK: aa aa aa aa aa aa aa aa ...
read 16 bytes at 0x14000000 (FLASH-16)...  OK: 15 05 00 ea fe ff ff ea ...
read 64 bytes at 0x14050000 (KERNEL-64)... OK: 27 05 19 56 e2 8a ab 68 ...
                                               ^^^^^^^^^^^ uImage magic

Two regression tests in TestRecvPacket:

• two whole packets in one chunk → both come out in order
• three packets (READY + DATA + ACK) in one chunk → all three come out

2. RackController.fastboot(...) — host counterpart to pod-side BootROM upload

The pod's TCP-bridged UART has ~50 ms WiFi RTT per round-trip. The HiSilicon SPL boot protocol's per-frame ACK loop (150 ms timeout, dozens of frames per upload) couldn't survive that — every attempt failed at PRESTEP0 even with the fixes from #85.

The companion rack-firmware change adds POST /fastboot which runs the entire BootROM upload sequence on the ESP32-S3 itself: handshake (flood 0xAA, watch for 0x20 markers), DDR step (PRESTEP0/DDRSTEP0/optional PRESTEP1), SPL upload, agent upload. ACK latency drops from ~50 ms (WiFi) to ~1 ms (local UART), making the whole sequence reliable.

This PR adds RackController.fastboot(profile, spl, agent) that packs everything into a single binary blob (load addresses + PRESTEP/DDRSTEP/PRESTEP1 + SPL + agent), POSTs it, and returns the pod's phase-by-phase JSON.

End-to-end against 10.216.128.69 (hi3516ev300):

POST /fastboot (41 834 bytes blob)
  result: {'success': True, 'last_phase': 'done',
           'elapsed_ms': 4552, 'handshake_markers': 5}
agent INFO: jedec=ef4018 (W25Q128), flash=16 MB, version=2, caps=0x7f
read 64 b @ 0x14000000: 15 05 00 ea fe ff ff ea ... (uImage payload)

~4.5 s wall-clock for the full SPL+agent bring-up vs. 100% failure before.

Test plan

• uv run pytest tests/ -x -v --ignore=tests/fuzz (457 passed / 2 skipped)
• uv run ruff check src/defib/ tests/
• uv run mypy src/defib/ --ignore-missing-imports
• Soak the agent path against a local serial transport to confirm the leftover-buffer change doesn't regress pyserial flows (it shouldn't: those go through _recv_packet_sync, untouched).

🤖 Generated with Claude Code