1afe1b7134
Two harness problems, one fixed and verified, one diagnosed. Bind: three consecutive attempts failed and the session aborted rather than flying an unattended craft, which is last iteration's guard working as intended. The cause is that entities2 self finds the player by motion between two samples, so a craft sitting still at mission start is invisible. The session now holds the throttle for three seconds before each attempt. Verified: the next run bound immediately and produced 11 losses with zero confirmed arrivals, making fourteen runs without one. One increase, 10 to 11, was surfaced and correctly not counted. Witness: the frame-rate-band selection is still unreliable. It found only five candidates in band and reported 0 of 5 moved in samples where craft were being destroyed, and a counter genuinely running at 24/s cannot fail to advance across a 15 s sample -- it would gain about 360. They are bursty counters that moved during the 3 s calibration and then stopped. The cause is mine. When the witness was bolted into wave7_probe the candidate search was narrowed to a 4 MB window, while timer_probe searched the whole 32 MB region and found 286 candidates with a clean cluster near 17/s. The narrowing was never justified, it was just cheaper to write. Now searches the full region once at startup, which is a one-off cost rather than per sample, and warns explicitly when fewer than eight witnesses are available so a weak vote is visible instead of silently trusted. Not yet run. Worth recording: this is the third attempt at this witness, and all three failures share one pattern -- a shortcut in selecting the witness rather than in the voting logic. Each was caught only because the flagged samples contradicted the loss events in the same output. That internal contradiction is the real check and should survive into any future version.