re: the periodic rescan was the freeze driver; first trustworthy negative

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.

tools/re-capture/wave7_probe.py

@@ -16,7 +16,13 @@ wave3 = importlib.util.module_from_spec(_w3); _w3.loader.exec_module(wave3)
 
 ROSTER_VT = struct.pack('>I', 0x820AF030)
 DELTA, WIN, LINK, HULL = 0x130, 0x400, 0x08, 0x154
-BASELINE, RESCAN = 116, 180   # rescan halved in frequency: it is a 32 MB read
+BASELINE = 116
+# Periodic rescan DISABLED. It was a 32 MB read every 90-180 s, the only
+# recurring heavy cost left, and it exists to catch craft that appear from
+# nowhere -- which the roster work already showed does not happen: every
+# participant is allocated at mission load, so an arrival is a state change on
+# an existing craft, not a new allocation. Set >0 to re-enable.
+RESCAN = 0
 
 def scan_vt(fd, size, vt):
     out = []
@@ -98,24 +104,25 @@ def main():
     # failed to advance in 15 s windows where craft were being destroyed, i.e.
     # they are bursty, not frame counters. timer_probe searched the WHOLE 32 MB
     # region and found 286 with a clean cluster at ~17/s. Pay the one-off cost.
-    # Full-region calibration found the witnesses but reads 32 MB twice, and this
-    # probe is already suspected of provoking the freezes. Sample the region
-    # SPREAD OUT instead: 8 windows of 512 KB, 4 MB total but covering the whole
-    # span, which found 6500 candidates' worth of diversity in practice.
+    # REVERTED to the full-region calibration. Trimming it to 8 spread 512 KB
+    # windows to save I/O found only 17 candidates, none of them frame counters,
+    # and the witness then reported 0/17 stalled on EVERY sample of a run that
+    # recorded 13 losses -- a total contradiction. The frame-rate cluster is
+    # sparse and spread sampling misses it. Two 32 MB reads once at startup is
+    # the price of a witness that works; the recurring cost was the periodic
+    # rescan, and that is what has been cut instead.
     lo, hiw = gmem.va_to_off(0xBC000000), gmem.va_to_off(0xBE000000)
-    step = (hiw - lo) // 8
-    wins = [(lo + i * step, min(512 << 10, step)) for i in range(8)]
     def grab():
-        return b''.join(os.pread(fd, n, o) for o, n in wins)
+        out, pos = bytearray(), lo
+        while pos < hiw:
+            n = min(1 << 24, hiw - pos); out += os.pread(fd, n, pos); pos += n
+        return bytes(out)
     a = grab(); time.sleep(3.0); b = grab()
     cands = []
-    base_of = []
-    for o, n in wins: base_of += [(o, i) for i in range(0, n, 4)]
     for k in range(0, min(len(a), len(b)) - 3, 4):
         va, vb = struct.unpack_from('>I', a, k)[0], struct.unpack_from('>I', b, k)[0]
         if va < vb and 5 < (vb - va) / 3.0 < 200:
-            wo, off = base_of[k // 4]
-            cands.append((wo + off, round((vb - va) / 3.0)))
+            cands.append((lo + k, round((vb - va) / 3.0)))
     # The MODAL cluster is not the frame counter. One run picked a modal rate of
     # 93/s, and only 11 of 31 of those advanced during active combat -- they are
     # subsystem counters that tick in bursts. timer_probe measured the frame-rate
@@ -143,7 +150,7 @@ def main():
     while time.time() - t0 < secs:
         time.sleep(every)
         el = round(time.time() - t0)
-        if time.time() - last_rescan > RESCAN:
+        if RESCAN and time.time() - last_rescan > RESCAN:
             craft = enumerate_craft(fd, defs, want); last_rescan = time.time()
         cur = collections.Counter(c[2] for c in craft if c[2] and alive(fd, c[0]))
         st = ''