d674fee457
Two changes this iteration, one failed and reverted, one that worked. Trimming the witness calibration to eight spread 512 KB windows instead of the full region found 17 candidates, none of them frame counters, and the witness then reported 0 of 17 stalled on every sample of a run that recorded 13 losses. That is a total contradiction, caught by the same internal check that exposed the previous three witness failures. The frame-rate cluster is sparse and spread sampling misses it. Reverted: two 32 MB reads once at startup is simply the price of a witness that works. The recurring cost was the periodic rescan, a 32 MB read every 90 to 180 seconds, and it exists only to catch craft appearing from nowhere -- which the roster work already established does not happen, since every participant is allocated at mission load and an arrival is a state change rather than an allocation. Disabled. The result is the first fully clean probed run: 3875 candidates, 32 witnesses at 11/s, no stall flag on any sample from t=0 to t=210, and eight losses spread across it. Previous probed runs froze at 27, 45, 83, 183 and 255 seconds. This one ended on the turn timeout. One run, so not proven, but together with the clean no-probe control it points at recurring heavy reads rather than at memory reading as such. That also produces the first arrival result that means what it says. Every earlier one carried a caveat -- a stalled guest, an unvalidated witness, a probe degrading what it measured. This one has a validated witness reporting no stalls, a demonstrably live guest, and a clean end: zero confirmed arrivals over 210 s of verified-live Stage 02 flight, roughly 115 game-seconds, while the player destroyed eight craft. It does not settle the question. The route table's t = 170, 210 and 240 entries remain out of reach in a single turn. But it does establish that nothing arrives in the first ~115 game-seconds of phase 1 under those conditions, which none of the previous fifteen runs could honestly claim.