Measure fsync-under-execution_mutex jitter during concurrent checkpoint flushes

[alphastorm]

From the v0.4.0 pre-freeze review (gemini U1, deferred: not answerable from source). Synchronous checkpoint staging fsyncs while holding execution_mutex; the open question is whether multi-gigabyte flushes under saturated NVMe write load induce queue timeouts or token jitter in concurrent streaming requests. The v0.4.0 qualification measured single-session saves only. Wanted: a two-session measurement (one streaming, one flushing 7+ GB) with decode-host and wait-per-round deltas, on the appliance profile.

[alphastorm]

First live datapoint for the measurement this issue asks for, from the 2026-08-31 fanout probe on the released 5090 container (67.7K-token session, ~5.0 GB generation): every same-session follow-up admitted immediately after a completed turn paid ~+15 s versus its baseline (warm continuation 14.6 s server ttft vs 0.57 s when the prior state had settled; root branches 40 s vs 25.4 s cold). This looks like the post-turn state capture/settlement serializing the next admission - the per-turn tax the packet predicted. Receipt: omp-ninfer docs/measurements/2026-08-31-fanout-probe-main.json. The full two-session streaming-jitter measurement is still wanted; this bounds the single-session case.