re: MCOL solved -- a closed triangle collision mesh in a uniform grid

The 0x50 header word, which the first section of this page had dismissed as "a
large value", is two u16 counts: vertices and triangles.  They give the two
remaining blocks their stride, and every derived length is exact in 11/11 --
len(0x54) == align16(12*nv), len(0x58) == align16(6*nt), and nt equals the
bounding-sphere count decoded last iteration.

Checks that cannot pass by accident:

  * sphere i is the TIGHT bounding sphere of triangle i, 4768/4768, with
    max|v-c|/r median 0.99990 (a fixed 1.0001 epsilon), against a 1.32%
    random-triangle control;
  * the mesh is watertight -- every edge shared by exactly two triangles,
    7152/7152, zero degenerate triangles, zero unreferenced vertices;
  * the two smallest objects are 8 vertices and 12 triangles whose positions
    are the eight +-250000 corners of the map bbox: a bare bounding cube.

The cell lists are a correct broad phase: with an exact triangle/box SAT test
only 3 overlapping triangles in 18 577 entries are absent, so a query walking
one cell's list cannot miss a hit.  The 730 conservative extras bracket the
builder's own test between exact-SAT and AABB, which retires the 18 unexplained
"sphere misses" from the previous commit as that same margin.

mcol_probe.py gains `mesh` and `obj`; `verify` now runs all three checks and its
output is recorded in docs/re/data/mcol-verify.txt.

docs/re/BACKLOG.md

@@ -393,9 +393,24 @@ search cannot find a *schedule*.
   `tools/re-capture/mcol_probe.py verify`.
   ⚠️ The stale ≈**0.75×** ratio I had recorded as "too consistent to be
   coincidence" was **12/16** — my own wrong stride, not a fact about the data.
-  ❔ Still open: the `0x54` and `0x58` blocks (the geometry these spheres bound;
-  neither has a constant stride against the sphere count), and 18 cell entries
-  (0.10 %) whose sphere misses its cell by 0.4–13 %.
+  ✅✅ **`MCOL` SOLVED the same day — it is a closed triangle collision mesh.**
+  The `0x50` word is **two `u16` counts** (vertices, triangles), which gives the
+  last two blocks their stride: `len(0x54) == align16(12·nv)` and
+  `len(0x58) == align16(6·nt)` in **11/11**, and `nt` == the sphere count in
+  **11/11**. Sphere *i* is the *tight* bounding sphere of triangle *i* —
+  **4 768/4 768**, `max‖v−c‖/r` median 0.99990 (a fixed 1.0001 epsilon), against
+  a 1.32 % random-triangle control — and the mesh is **watertight**: every edge
+  shared by exactly two triangles, **7 152/7 152**, zero degenerates, zero
+  orphan vertices. The two smallest objects are 8 vertices / 12 triangles = the
+  map's bounding cube. The cell lists are a **correct broad phase**: only **3**
+  overlapping triangles in 18 577 entries are missing, and the 730 conservative
+  extras place the builder's test between exact-SAT and AABB — which also
+  explains the 18 "sphere misses" above as that same margin.
+  `tools/re-capture/mcol_probe.py verify` reproduces it
+  ([`data/mcol-verify.txt`](data/mcol-verify.txt)); `mcol_probe.py obj` exports
+  any object as a Wavefront OBJ.
+  ❔ Still open: the objects are **not name-resolved**, so the map each belongs
+  to — and the `MCOL`↔`REGN` pairing — is unknown, as is the runtime consumer.
   See [`structures/mcol-collision.md`](structures/mcol-collision.md).
 * 🔴 **`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