re: kill-free HUD route for REMAINING OB; big-endian u32 assumption refuted

The correlation route is gated on marked-fighter kills, which the pilot manages
at about two per five minutes. ob_read.py already reads the counter off the
screen, so ob_by_hud.py matches the displayed value against memory directly and
needs no kills at all: screenshot, read the digits, keep heap words equal to that
value, intersect across readings.

Four readings at value 4 narrowed 6156 candidates to 4312, the expected slow
drift. Then the HUD read 11 and the intersection collapsed to zero. A word
holding this counter must equal 4 at the first four samples and 11 at the last,
and none does, so within the entity heap read as big-endian u32 the counter does
not exist. It may be u16, u8, little-endian, or outside that region. Both
previous hunts assumed big-endian u32 there, so this eliminates the assumption
rather than merely failing to find anything.

The displayed value also went up, from 4 to 11 over about 340 seconds. A pure
countdown of remaining marked targets should not rise, and the deployment work
says phase 1 gains no new participants. Three readings are possible and none is
tested: the cell being read is not REMAINING OB, the digits are misread, or the
counter genuinely counts something that can increase. The two clean readings
scored 0.95 to 0.98 against their templates, but 4 and 11 use only digits that
are in the strip, which is exactly the selection effect that would hide a wrong
reading -- the template set covers 0 1 2 4 8 only, and most samples came back
unreadable.

Next is widening the scan to u16 and u8 and to little-endian, and beyond the
entity heap, which is a change to one function and costs no combat. Extending
ob_digits.png with the missing digits would also raise the sample yield, since
only two of eleven readings in a 480 s run were usable.

docs/re/BACKLOG.md

@@ -609,6 +609,17 @@ search cannot find a *schedule*.
   *fighters*, so a marked-target counter should ignore turrets; it also rules out
   `REMAINING OB` being a general kill tally (it ignored ten turret deaths).
   ❔ Still needs 2–3 `e010` events; one clean 220 s run produced **zero**.
+* ✅🔴 **(2026-08-24) Kill-free HUD route works; BE-`u32` assumption REFUTED.**
+  `ob_by_hud.py` reads the counter off screen (`ob_read.py`) and intersects heap
+  words equal to it — **no kills needed**. Four readings at HUD=4 narrowed
+  6156→4312, then HUD read **11** and the intersection collapsed to **0**. ⇒ within
+  `0xBD000000–0xBE000000` as **big-endian u32 the counter does not exist**; it may
+  be u16/u8/LE or outside the region. Both previous hunts assumed BE-u32, so this
+  eliminates the assumption rather than just failing. 🟡 **The value went UP, 4→11**,
+  which a pure countdown should not do — candidates: wrong HUD cell, misread digits
+  (template strip covers only **0 1 2 4 8**; most samples read `00?`/`???`), or a
+  counter that can rise. **Next: widen the scan to u16/u8 and LE, and beyond the
+  heap** — one function, no combat cost. Also extend `ob_digits.png`.
 * ~~🚧 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**.

docs/re/remaining-ob-hunt.md

@@ -156,3 +156,62 @@ minutes.
 
 One clean 220 s run this iteration produced **zero** `e010` kills, which is the
 limit stated plainly.
+
+---
+
+# ✅ A kill-free route via the HUD — and it refutes the u32 assumption (2026-08-24)
+
+The correlation route is gated on marked-fighter kills, which the pilot gets at
+about two per five minutes. But `ob_read.py` already reads the counter off the
+screen, so the value can be matched against memory directly — no kills needed.
+
+`tools/re-capture/ob_by_hud.py`: screenshot → read the digits → keep heap words
+equal to that value → intersect across readings.
+
+```
+t=  7s  HUD=4   words==4: 6156  -> candidates 6156
+t= 42s  HUD=4   words==4: 6256  -> candidates 5153
+t= 75s  HUD=4   words==4: 6327  -> candidates 4620
+t=108s  HUD=4   words==4: 6451  -> candidates 4312
+t=142s .. t=312s   HUD unreadable ('00?', '??1', '???')
+t=347s  HUD=11  words==11: 1052 -> candidates 0
+```
+
+## 🔴 Refuted: the counter is not a plain big-endian u32 in the entity heap
+
+Four readings at value 4 narrowed 6156 → 4312 — the expected slow drift. Then the
+HUD read **11**, and the intersection collapsed to **zero**.
+
+A word that genuinely holds this counter must equal 4 at the first four samples
+*and* 11 at the last. None does. So within `0xBD000000–0xBE000000`, read as
+big-endian `u32`, **the counter does not exist**. It may be `u16`, `u8`,
+little-endian, or simply outside that region.
+
+That is worth having: both hunts so far assumed BE-`u32` in the entity heap, and
+that assumption is now eliminated rather than merely unproductive.
+
+## 🟡 The displayed value went UP, 4 → 11
+
+Over ~340 s the counter *increased*. A pure countdown of remaining marked targets
+should not do that — unless targets were added, which the deployment work says
+does not happen for phase 1
+([mission-phase-deployment.md](mission-phase-deployment.md)).
+
+Possible readings, none tested: the cell being read is not `REMAINING OB`; the
+digits are misread (the template strip only covers **0 1 2 4 8**, so 3/5/6/7/9
+come back as `?` — the many unreadable samples above); or the counter genuinely
+counts something that can rise.
+
+The two clean readings scored 0.95–0.98 against their templates, so a misread of
+those specific frames is unlikely — but "4" and "11" use only digits that *are*
+in the strip, which is exactly the selection effect that would hide a wrong
+reading.
+
+## Next
+
+Widen the encoding: search `u16` and `u8`, little-endian as well as big, and
+beyond the entity heap. That is a change to one scan function, and unlike the
+kill-driven route it costs no combat.
+
+Also worth extending `ob_digits.png` with the missing digits — most samples were
+unreadable, which is why only two data points survived a 480 s run.