re: mission TIME is the liveness oracle, and it explains the earlier "0 movers"

The OB kill test did not run -- the guest froze about a minute into the mission --
but sampling the HUD's own mission clock beside the counter caught it instantly.
Twelve samples over ~4 minutes of wall time: the first reads TIME 00:43.24, every
one after reads 01:02.23 unchanged, with REMAINING OB 004 throughout.  frozen.py
agrees (max_pixel_delta=0), movers in the entity window are 0, and screen_id still
says `flight` with the process alive.

Worth a file because the mission clock defeats both traps this corpus has paid
for: it is the simulation's own counter, so neither a frozen world nor a finished
one advances it, where screen_id and pixel-churn are fooled by a GAME OVER screen
that animates.  Rule recorded: "X never changed" is only evidence if TIME changed
across the same window.

It also closes an open ❔ from earlier this session -- entity-position-anchor-
refuted.md's "0 of 64 regions changed across 357 MB, cause unknown, not
reproduced".  Same signature, now reproduced: it was this freeze.

Still unrun for the fourth iteration: the kill test itself.  Not conceptually
blocked -- blocked by attrition, with this run dying at t~62s, before even the
t=120 arrival the trajectory prediction needs.

docs/re/mission-time-is-the-liveness-oracle.md

@@ -0,0 +1,71 @@
+# ✅ The HUD's mission TIME is the liveness oracle — and it closes the "0 movers" mystery
+
+Measured 2026-08-27, Stage 02 (guarded route, stage asserted), attempting the
+`REMAINING OB` kill test.
+
+## What happened
+
+The kill test **did not run**: the guest froze about a minute into the mission.
+It was caught immediately, and by the cheapest possible means — sampling the
+HUD's own **mission clock** beside the counter.
+
+![TIME frozen at 01:02.23](captures/mission-time-frozen-timeline.png)
+
+Twelve samples over ~4 minutes of wall time. The first reads `TIME 00:43.24`;
+every one after reads **`01:02.23`**, unchanged, with `REMAINING OB : 004`
+throughout.
+
+Confirmed three independent ways at the same moment:
+
+| check | verdict |
+|---|---|
+| mission `TIME` | frozen at `01:02.23` |
+| `frozen.py` | `frozen max_pixel_delta=0 gap=6.0s` |
+| movers in the entity window | **0** |
+| `screen_id.py` | still `flight` |
+| process | alive |
+
+## ✅ Why this is worth a file: TIME beats every other liveness check
+
+This corpus has twice recorded a confident negative that turned out to be about a
+dead world — the in-mission freeze, and the **GAME OVER screen animating** while
+tools reported "the counter never moved"
+([mission-freeze-and-ob-flag.md](mission-freeze-and-ob-flag.md)). Both defeated
+`screen_id.py`, and the second defeated pixel-churn detection too, because a
+finished mission still animates.
+
+**The mission clock defeats neither trap, because it is the simulation's own
+counter.** A frozen sim does not advance it; a finished mission does not advance
+it; a live one always does. It costs one crop of an already-taken screenshot.
+
+**Rule:** sample `TIME` beside any in-mission measurement. A reading of "X never
+changed" is only evidence if `TIME` changed across the same window.
+
+Crop used here: `convert shot.png -crop 210x46+995+38 +repage time.png`
+(the `REMAINING OB` digits are `-crop 150x46+1085+232`). Montaging N crops into
+one strip makes a whole run's timeline readable in a single look.
+
+## ✅ It also closes an earlier ❔ from this session
+
+[`entity-position-anchor-refuted.md`](entity-position-anchor-refuted.md) recorded
+a session where **0 of 64 sampled regions changed across the whole 357 MB
+mapping** while the HUD rendered, and left the cause ❔ — "not reproduced; cause
+unknown". It is now reproduced, with a diagnosis: that was **this freeze**. The
+signature matches exactly — movers 0, screen still `flight`, process alive at
+full CPU, and nothing in guest memory advancing.
+
+So that open question is answered, and the general lesson it was filed under
+stands reinforced rather than replaced.
+
+## ❌ What did NOT get done
+
+The `REMAINING OB` kill test — kill one `e010`, expect the counter to fall by
+exactly 1 — is **still unrun**, now for the fourth iteration. It is not blocked by
+anything conceptual; it is blocked by attrition. Roughly half of Stage 02 runs
+end early, and this one froze at t≈62 s, before the t=120 arrival that the
+[trajectory prediction](ob-counts-marked-attackers.md) needs, let alone before any
+kill.
+
+❔ **The freeze's cause remains uninvestigated.** This run establishes only that
+it happens, that it happened at t≈62 s of mission time, and that TIME detects it
+in one crop.