re: correct a mislabelled blocker -- the world unit needs a run, not a waiver

I wrote "blocked on the oracle" for the unit-to-metre conversion.  That was a
mislabel: red is for what the container cannot do, and run-canary works here.
What the km-name sweep actually established is narrower -- no STATIC test can
settle it, because the disc has exactly one size-bearing asset name.

The run is well-supported by tooling that already exists: findplayer.py
recovers the player position triple from motion, the HUD prints the distance to
the selected target in the game own units, and the same separation read both
ways is the conversion.  Recorded as amber with the experiment written out.

docs/re/BACKLOG.md

@@ -456,10 +456,14 @@ search cannot find a *schedule*.
   **108/112** ship/mob stems are prefixed by one of the 480 resource ids, against
   a **0/112** shuffled-character control, and correctly **0/46** on asteroids. A
   `CollisionSet` entry is `<GameResourceID>[_<part>]_cmesh`.
-  🔴 **The world unit is BLOCKED on the oracle.** Sweeping every pak for a
-  km-bearing name returns `mapmesh_box_500km` and **nothing else** (162 refs, all
-  that one pair) — the convention has no second instance, so no static test can
-  settle it. Needs a measured in-game traversal against the flight model.
+  🟡 **The world unit needs a run — it is NOT blocked** (label corrected
+  2026-08-26). Sweeping every pak for a km-bearing name returns
+  `mapmesh_box_500km` and **nothing else** (162 refs, all that one pair), so no
+  *static* test can settle it; that is not the same as blocked, and 🔴 is for
+  what the container cannot do. The experiment: `findplayer.py` gives the player
+  and target position triples in world units, the HUD prints the distance between
+  them in the game's own units, and the ratio is the conversion. All of
+  `run-canary` / `pad.py` / `screenshot` / `findplayer.py` already exist.
   `tools/re-capture/collisionset.py verify|list|obj`
   ([`data/collisionset.txt`](data/collisionset.txt)).
   ❔ Still open: no material/surface-type field exists in the record, and the

docs/re/structures/collisionset.md

@@ -128,9 +128,26 @@ My objection's own premise did survive its check: `rou_e010` is a real
 trailing `_S` means "small" is a further guess — there are `_EX4`, `_HF` and
 `_HF_Wayne` variants of the same unit — so it is suggestive, not evidence.)
 
-🔴 **Blocked on the oracle.** An independent scale reference — the flight model's
-speed values against a measured traversal time in the running game — is the only
-route left, and it needs an emulator run rather than the disc.
+🟡 **Not blocked — just not run yet.** An earlier version of this line said
+"🔴 blocked on the oracle", and that was a mislabel. 🔴 is for what the container
+*cannot* do; `run-canary` works here, and measuring the game is what it is for.
+What the sweep above actually established is narrower and worth keeping: **no
+*static* test can settle this**, because the disc contains exactly one
+size-bearing asset name.
+
+The experiment is well-supported by tooling that already exists:
+
+1. `findplayer.py` recovers the player craft's live position triple from guest
+   RAM by its motion, so a mission run yields positions in world units.
+2. The HUD prints a **distance to the selected target** in the game's own units
+   of measure.
+3. The same separation read both ways — Euclidean distance between the two
+   position triples, against the number the HUD displays — is the conversion,
+   measured rather than inferred from a filename.
+
+`pad.py` scripts the target-select input (Ⓐ pressed **twice**, per `AGENT.md`),
+and `screenshot` crops to the game surface. Nothing here needs anything the box
+lacks. It is the next run.
 
 Reproduce with `tools/re-capture/collisionset.py verify` / `list`
 ([`../data/collisionset.txt`](../data/collisionset.txt)); `collisionset.py obj`