re: OB address is run-dependent; watcher hunts it, HUD reader gated on confidence

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.

docs/re/BACKLOG.md

@@ -657,6 +657,19 @@ search cannot find a *schedule*.
   objective targets are being **added during the mission** — the arrival question
   again, now with a one-word signal instead of a 32 MB scan. **Next: watch this
   address across a whole mission.**
+* ✅🔴 **(2026-08-25) OB address is RUN-DEPENDENT; watcher now self-sufficient.**
+  Two fresh launches: `mem@0xbdb59668` = **3165285888 (MISMATCH)** then **4
+  (MATCH)** against HUD=4. The confirmation gate refused to report from the bad
+  one — the old "recurs in ~5 of 7 runs" note is right. `ob_watch.py` now **hunts
+  the address on the current run** when confirmation fails. ✅ HUD reader is now
+  **confidence-gated** (every digit ≥0.80, margin ≥0.05 — the rule `ob_read`'s own
+  docstring states), closing the hole that produced the wrong `u32be` refutation.
+  🔴 **OB flat at 4 for 250 s** (witness clean, 0/50 stalled) while the pilot
+  fired on **1635 of 1964 ticks** at marked attackers — constant fire, zero
+  decrements, so it destroyed none. Fire rate itself rose from 4.6% to 83% with
+  no more kills. ❔ **The earlier 4→8→12 rise is NOT reproduced** — both readings
+  were HUD-confirmed, so the rise is not a stable property of the first five
+  minutes; recorded as unreproduced rather than explained away.
 * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ — **superseded, see above**;
   it rested on an untested assumption that a turn is one shell call. 595 s shell cap − ~220 s boot (a ~190 s title movie that cannot be
   tapped through) − ~25 s startup = **~350 s observation ≈ 193 game-seconds**.