docs(roadmap): §9 client→host network speed test (bitrate prerequisite)

A bandwidth probe over the punktfunk/1 data path so a user-settable bitrate can be
informed by what the network actually sustains (throughput/loss/jitter), surfaced in
the client UI + web console. Reuses the existing Session/FEC plumbing.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/roadmap.md

@@ -164,3 +164,19 @@ client) is built and live. Two changes harden it from "works" to "secure by defa
     is a client-agent task.
 
   PIN pairing (§8a) stays the bootstrap — the first device, or when no approver is online.
+
+## 9. Client→host network speed test *(next — prerequisite for a user-settable bitrate)*
+
+Before exposing a user-settable bitrate, the client needs a way to **measure what the network
+actually sustains** between it and the host, so the bitrate picker is informed (suggest/cap a safe
+value) instead of guesswork that ends in a stuttering stream.
+
+- A short **bandwidth probe over the punktfunk/1 data path**: the host bursts a few seconds of
+  FEC-encoded payload (sized like a real high-bitrate stream) while the client measures sustained
+  throughput + packet loss + jitter, and reports the achievable Mbps (plus the FEC-recovered
+  headroom — the GF(2¹⁶) Leopard wall-breaker is exactly what makes a high-loss link still usable).
+- Surface it in the client UI ("Test network" → "~XXX Mbps · recommended bitrate YYY") and the web
+  console; feed the result into the bitrate control (clamp/suggest) once that lands.
+- Reuse the existing `Session`/FEC plumbing — a probe is just a non-video AU stream the client
+  byte-counts + times; no new transport. Pairs with bitrate negotiation (bitrate in Hello/Welcome,
+  alongside the mode renegotiation already in place).