feat(coord): consolidate H2 recv/JSON buffers into one dynamically-sized window

[fudio101]

Summary

Ports piece (a) of djorr5/microlink's 67b230b2 — dynamic H2 RX window sizing — tracked as issue #38 in FORK_PRS.md row 19. Piece (b) (ip4_route_src_hook) is unrelated and untouched, still tracked separately as #39.

• do_fetch_peers() previously allocated two fixed 512KB PSRAM buffers: an H2 receive buffer and a separate JSON parse buffer. Merged into one buffer — the extracted MapResponse JSON is now compacted in place via memmove instead of copied into a second buffer, halving peak footprint (~1MB → ~512KB at defaults, less under heap pressure).
• The buffer size is chosen at connect time by new choose_h2_rx_window_size() (ml_coord.c): largest free block across SPIRAM/internal heap, minus a 32KB safety margin, clamped to [64KB, CONFIG_ML_H2_BUFFER_SIZE_KB]. Stored in a new ml->h2_rx_window_size field, threaded through ml_h2_build_preface()'s signature and do_h2_preface()'s window-update math.
• CONFIG_ML_JSON_BUFFER_SIZE_KB removed — the merged buffer only needs one size knob now. CLAUDE.md/README.md updated to match.

Adapted, not a literal port: kept this fork's existing frame_buf scratch-then-copy pattern in the initial H2 receive loop, rather than reading noise_recv() directly into the shrinking destination window as the source commit does. This fork's noise_recv() returns -1 without draining the ciphertext off the socket when a frame doesn't fit the caller's buffer — reading straight into a near-full window would risk desyncing the coordination stream. The scratch-buffer indirection avoids that regardless of remaining space.

Credit to djorr5/microlink for the original fix.

Test plan

• Full clean pio run -e lilygo-t-display-s3 against zen-clock (a real downstream consumer, LilyGo T-Display-S3/ESP32-S3) with idf_component.yml's override_path pointed at this branch's working tree — bootloader + firmware built and linked with zero errors. dependencies.lock confirmed the build resolved fugo101/microlink from the local path, not the registry.
• Flashed to real hardware and confirmed working against a real tailnet (husky-firefighter.ts.net). Boot log through do_fetch_peers():

  H2 rx window: 128KB (largest free block 6144KB, ceiling 128KB)
  H2 preface sent (61 bytes, conn window=128KB)
  H2 END_STREAM detected after 13 Noise frames (22KB, 1189ms)
  Accumulated 22KB of H2 data from Noise frames (1189ms)
  MapResponse JSON: 22592 bytes
  MapResponse top-level fields: ... Peers (array, size=5)
  

  No truncation warnings, no crashes. All 5 real tailnet peers then completed WireGuard handshakes (direct + DERP) normally, confirming the consolidated buffer + in-place memmove compaction didn't corrupt the accumulated H2/JSON data across a real 13-frame, 22KB MapResponse.
• The adaptive clamp-under-heap-pressure branch specifically (window shrinking below the compiled ceiling) was not exercised — this board's free PSRAM (6144KB largest block) is far above its 128KB ceiling, so the window always resolved to the full ceiling. Would need a genuinely RAM-constrained board or artificial heap pressure to observe the clamp actually engaging.

Closes #38

🤖 Generated with Claude Code