re: REMAINING OB found and verified — big-endian u32 at 0xbdb59668

Ported onto the shared harness, the HUD changed from 4 to 8 and the intersection
collapsed in a single step: one u32be survivor at 0xbdb59668, with the u16be and
u8 hits at 0xbdb5966a and 0xbdb5966b being the low half and low byte of that same
word.

Verified live rather than asserted. Reading screenshot and memory together three
times, the one legible HUD frame showed 012 against mem@0xbdb59668 = 12; the
other two frames were unreadable rather than mismatched. This independently
rediscovers the address the earliest sessions found by digit-transition hunting,
by a completely different method.

It also corrects an earlier conclusion. A previous run intersected HUD readings
of 4 and then 11, got zero survivors in every encoding, and that was written up
as eliminating big-endian u32 for the whole region. This run shows u32be holds
the counter, so the refutation was wrong. The likely cause is the input:
ob_digits.png has templates for 0 1 2 4 8 only, so values containing other
digits are misread rather than rejected, and "11" was probably one of those. A
single bad reading poisons an intersection permanently, because it removes the
true address and nothing later can restore it. The lesson is that an
intersection method needs individually verifiable inputs -- the reader's
confidence scores were printed but never gated on.

One observation reopens the arrival question in a useful way: the counter
increases, 4 then 8 then 12 across about five minutes, measured in memory so not
a digit misread. A count of remaining marked targets that rises means targets
are being added during the mission. That does not contradict the deployment
finding, since the roster is fixed at load, but it does mean the game marks new
objective targets as the mission proceeds. Watching this one address across a
whole mission is now the obvious next experiment and costs almost nothing.

docs/re/BACKLOG.md

@@ -642,6 +642,21 @@ search cannot find a *schedule*.
   watch in ~40 lines vs 150, first live run clean — 116 roster, 32 witnesses at
   10/s, **0 stalled**, 7 losses, TSV written incrementally. ⚠️ Existing probes
   deliberately **not** ported — they work and other docs cite their results.
+* ✅✅ **(2026-08-25) `REMAINING OB` FOUND AND VERIFIED: big-endian u32 at
+  `0xbdb59668`.** On the new harness, the HUD changed **4→8** and the intersection
+  collapsed in one step to a single `u32be` survivor (with `u16be`/`u8` hits being
+  the low half/byte of the same word). **Verified live**: HUD `012` vs
+  `mem@0xbdb59668 = 12`. Independently rediscovers the address the earliest
+  sessions found by digit-transition hunting.
+  🔴 **Corrects the earlier "u32be refuted"** — that came from intersecting on a
+  HUD reading of "11" which was almost certainly a misread, since `ob_digits.png`
+  only has templates for **0 1 2 4 8** and misreads rather than rejects other
+  digits. **A single bad input permanently poisons an intersection**; the reader's
+  confidence scores were printed but never gated on.
+  🟡 **The counter INCREASES: 4 → 8 → 12** in ~5 min, measured in memory. Marked
+  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.**
 * ~~🚧 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**.