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/remaining-ob-hunt.md

@@ -328,3 +328,62 @@ targets as the mission proceeds.
 
 Watching this one address across a mission is now the obvious next experiment,
 and it costs almost nothing.
+
+---
+
+# The address is run-dependent; the watcher now finds it itself (2026-08-25)
+
+## ✅ Confirmed run-dependent
+
+`ob_watch.py` verifies the address against a **confidence-gated** HUD reading
+before reporting anything. Two consecutive fresh launches:
+
+```
+run A   confirm: HUD=4  mem@0xbdb59668=3165285888   MISMATCH
+run B   confirm: HUD=4  mem@0xbdb59668=4            MATCH
+```
+
+So `0xbdb59668` is **not stable across launches** — it held garbage on one and
+the true counter on the next. The old note that it "recurs in about 5 runs of 7"
+was right, and the gate did its job: run A refused to report a series from an
+address that did not describe it.
+
+The watcher now **hunts the address on the current run** when confirmation fails,
+by the same intersection method, so it is self-sufficient rather than depending
+on a lucky launch.
+
+## ✅ The confidence gate is in
+
+`ob_read` returns `(best, second)` per digit and those scores were printed but
+never checked — one misread poisoned an entire intersection and produced a wrong
+refutation. A reading is now accepted only if **every digit scores ≥ 0.80 with a
+≥ 0.05 margin**, which is the rule `ob_read`'s own docstring states.
+
+## 🔴 OB did not move in 250 s, and the pilot fired 1635 times
+
+Run B, witness clean (0 stalled samples of 50):
+
+```
+OB = 4 for all 50 samples
+pilot: 1964 ticks targeting e010, fire=1 on 1635 of them
+```
+
+Constant fire at the marked attackers and **not one decrement**. The simplest
+reading is that it destroyed none of them — consistent with the combat limit
+recorded in [mission-objectives-text.md](mission-objectives-text.md), and with
+the earlier measurement of roughly two marked kills per five minutes.
+
+Worth noting the fire rate itself changed: an earlier diagnosis measured firing
+on **4.6 %** of ticks, this run on **83 %**. Whatever drives that, more shooting
+did not produce more kills.
+
+## ❔ The 4 → 8 → 12 rise is not reproduced
+
+The run that found the address saw the counter go 4 → 8 → 12 over five minutes,
+and that reading was itself confirmed against the HUD (`012` vs `mem=12`). This
+run was flat at 4 for a comparable window.
+
+Both observations are sound and they disagree, so the rise is **not a stable
+property of the first five minutes**. It presumably depends on mission progress
+this run never reached. Recorded as unreproduced rather than folded into either
+story.