re: backlog said REGN's coupling was unreachable statically -- it has been reached

I recorded the static coupling search as exhausted and needing PE code. The PE
work was done on auto/regn-reader and it solved the whole thing: REGN is a
tetrahedral navigation mesh, reached via the POF0 fixup table -- the loader's own
list of which words are pointers, so nothing needed guessing. Six sections;
position -> cell -> 32-byte item -> tet refs -> tetrahedron, with section 2 a
face carrying a plane plus its 3 vertices and the two tets either side.

Controlled checks: face through 3 of 4 tet vertices 253722/253722 against a
0.07-2.2% random control; portal cost equals face-centroid distance
380460/380460.

Also records against myself that the base is chunk+0x10 and my offsets here were
16 bytes early, that the plane arithmetic survives only because those fields
landed on the same bytes, and that my points-in-bbox count was never evidence --
a shift inside a homogeneous f32 array yields other floats from the same array.

Leaving the wrong conclusion in the backlog would have told the next reader the
avenue was closed when it was the one that worked.

docs/re/BACKLOG.md

@@ -355,11 +355,26 @@ search cannot find a *schedule*.
   (13 467/13 467 inside the bbox) and **section 2 is a plane list** — unit normal,
   signed distance, and a point, with `n·p + d = 0` to float round-off in
   **133 573/133 573**. Section 1 (96 B) still ❔ in meaning, though its slot
-  regions are censused. ❌ **The static coupling search is exhausted**: every
-  index-shaped field in the cell payload has been followed into all three
-  sections and checked for spatial agreement against controls — nothing above
-  chance. Settling it needs the PE code that reads `REGN`, not more correlation.
+  regions are censused. My static coupling search found nothing above chance —
+  every index-shaped field followed into every section, against controls — and
+  I concluded it needed the PE code rather than more correlation.
+  ✅✅ **SOLVED on branch `auto/regn-reader` (2026-08-26).** `REGN` is a
+  **tetrahedral navigation mesh**. The route in was the **`POF0` fixup table**:
+  it is the loader's own list of which words are pointers, so nothing had to be
+  guessed. There are **six** sections, and the chain is
+  `position → cell → 32-byte item → tet refs → tetrahedron`; section 2 is a
+  **face** carrying a plane plus its 3 vertices and the two tetrahedra either
+  side. Checked with controls: each face passes through exactly 3 of its tet's
+  4 vertices, **253 722/253 722**, against a 0.07–2.2 % random-face control;
+  portal cost equals the distance between face centroids, **380 460/380 460**.
+  ⚠️ **The base is `chunk + 0x10`, and my offsets on this page were 16 bytes
+  early** — the plane fields happened to land on the same bytes, so that
+  arithmetic survives, but the record boundary moves. My "13 467/13 467 points
+  inside the bbox" was **not evidence**: a shift inside a homogeneous `f32`
+  array yields other floats from the same array, so the test passes either way.
   See [`structures/regn-map-grid.md`](structures/regn-map-grid.md).
+  ❔ Still open there: the **runtime consumer** (not reached; a `float4`-aligned
+  header read with VMX loads leaves no displacement signature to search for).
 * 🔴 **`hidden/DefTables.pak` is NOT it** (checked 2026-08-24). The three
   unnamed schemas are more **model/render** tables in the same vocabulary as the
   named ones — `7e66225f` (283 objects) carries `RenderFrameModel`,