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**.