70b1e453a7
ob_watch.py verifies the address against a confidence-gated HUD reading before reporting anything, and two consecutive fresh launches settle the question: 0xbdb59668 held 3165285888 against a HUD of 4 on one, and exactly 4 on the next. The address is not stable across launches, the old note that it recurs in about five runs of seven was right, and the gate did its job by refusing to report a series from an address that did not describe that run. The watcher now hunts the address on the current run when confirmation fails, using the same intersection method, so it no longer depends on a lucky launch. The HUD reader is also gated now. ob_read returns a best and second score per digit and those were printed but never checked, which is how one misread poisoned an intersection and produced a wrong refutation of big-endian u32. A reading is accepted only if every digit scores at least 0.80 with a margin of at least 0.05, the rule ob_read's own docstring states. The measurement itself is a negative. With a clean witness, zero stalled samples of fifty, OB held at 4 for 250 seconds while the pilot targeted e010 for 1964 ticks and fired on 1635 of them. Constant fire at the marked attackers and not one decrement, so it destroyed none, which matches the roughly two marked kills per five minutes measured earlier. The fire rate itself rose from 4.6 % of ticks in an earlier diagnosis to 83 % here without producing more kills. Recorded as unreproduced rather than explained away: the run that found the address saw the counter rise 4, 8, 12 over five minutes, and that reading was confirmed against the HUD. This run was flat over a comparable window. Both observations are sound and they disagree, so the rise is not a stable property of the mission's first five minutes and presumably depends on progress this run never reached.