2b98105ac0
The graded output is the improvement. Instead of a single bit it reports how many witnesses agree, and the sequence tells a coherent story: 11, 9, 7, 4, 1, then 0 of 31, with the drop to zero at t=183 s coinciding exactly with the last loss and 106 s of nothing after it. That is a real freeze, identified. The threshold was wrong though. Flagging a stall at "fewer than half" marked the entire run stalled, including samples in which craft were destroyed, so 11 of 31 advancing is a healthy guest rather than a stalled one. The cause is the cluster choice: the modal rate was 93/s, far above the ~16.5/s frame rate timer_probe measured, and those are subsystem counters that tick in bursts and sit idle in most 15 s windows even while the game runs. Picking the modal cluster was convenient rather than principled. Fixed to prefer the cluster whose rate falls in the frame-rate band of 8-40/s, falling back to modal only if none exists, and to flag a stall only when zero witnesses advance, which is the signal the data actually supports. Not yet run. The uncomfortable part: this run used the cheap probe and still froze, at about 183 s. The previous iteration's "0 stalled samples" came from the unreliable single-word witness and cannot stand as validation. What the evidence supports now is that the no-probe control ran 300 s clean, the heavy probe froze at 27 to 255 s, and the cheap probe froze at 183 s -- one run on each arm. Cheap sampling plausibly helps but does not remove the freeze, and it is equally possible the freeze is stochastic and the control was lucky. Recorded as unresolved rather than resolved in the probe's favour. Practical consequence: the usable window is roughly three minutes per run, sometimes less, whether or not the probe is cheap. Experiments needing longer have to survive a freeze or be redesigned around one.