re: MCOL's u16 entries do not index the point block -- the bound-check was a false positive

Two tests. Counts modulo 3 are spread across all three residues (639/2063/1786),
so the u16 array is not a triangle list. And a B record is reached through a
specific cell, so a point it references should lie in that cell -- referenced
points score 0.79% against a 0.48% random-point control. Chance.

The contrast is the point. One section earlier the same u16 entries scored
18379/18379 (100%) on 'are these valid point indices'. I flagged that at the
time as the weak bound-check and recorded it as consistent rather than as a
finding. The caution was right: the powered version of the same question now
returns chance, and had the 100% been written up as the decode this page would
carry a confident false statement about MCOL's geometry.

Fifth appearance of the pattern across REGN and MCOL and the first time both
halves have been run on the same field, so the page now states it plainly: a
bound-check asks whether something could be an index, and the answer is set by
the size of the target collection rather than by the field's meaning.

Datum for the next attempt: the maximum u16 is consistently about 0.75x the
point count (923/1232, 1019/1360, 1163/1552, 59/80), too consistent to be
coincidence and not explained.

docs/re/structures/mcol-collision.md

@@ -234,6 +234,52 @@ evidence.)
 which is the same shape as `REGN`'s `cell → item → refs → geometry`, as the two
 formats' shared header and shared count-1 convention already suggested.
 
-❔ Still open: the `0x54` and `0x58` blocks (neither is reached by this chain),
-what the indexed points form — triangles would want n divisible by 3 — and the
-44-vs-4 488 accounting is exact, so there is no second pointer species to find.
+❔ Still open: the `0x54` and `0x58` blocks (neither is reached by this chain).
+What the `u16` entries index is **not** the point block — see immediately below.
+
+## ❌ The `u16` entries do NOT index the point block — and the weak test said they did
+
+**2026-08-26.** Two tests, and the contrast between them is the point of this
+section.
+
+**Not a triangle list.** If the `u16` array held triangle corners, every count
+would be divisible by 3. Counts modulo 3 across all objects:
+
+    n % 3 == 0   639        n % 3 == 1   2 063        n % 3 == 2   1 786
+
+Spread across all three residues. Refuted.
+
+**Not cell-local either.** A B record is reached *through* a specific cell, so a
+point it references should lie in that cell. With a random-point control:
+
+| | |
+|---|---|
+| referenced point inside the cell that reached it | 142 / 17 871 = **0.79 %** |
+| a random point inside that cell (control) | 85 / 17 871 = **0.48 %** |
+
+Chance. So whatever the `u16`s address, it is not the `0x5C` point block in any
+spatially meaningful way.
+
+### ⚠️ This is the bound-check hazard caught in the act
+
+One section above, the same `u16` entries scored **18 379 / 18 379 (100 %)** on
+"are these valid `0x5C` point indices". I flagged that at the time as the weak
+bound-check rather than evidence, and recorded it as *consistent* rather than as
+a finding. **That caution was correct**: the powered version of the same question
+now returns chance.
+
+This is the fifth appearance of the pattern across `REGN` and `MCOL`, and the
+first time both halves have been run side by side on the same field, so it is
+worth stating exactly:
+
+> A bound-check asks *"could this be an index?"*. Almost always, yes — the answer
+> is set by how large the target collection is, not by whether the field means
+> anything. The powered version asks *"does the thing it points at make sense
+> where it was reached from?"*, and only that version can be wrong.
+
+Had the 100 % been written up as the decode, this page would now carry a
+confident and false statement about `MCOL`'s geometry.
+
+❔ What the `u16`s index is open. A datum for the next attempt: the maximum
+`u16` is consistently ≈ **0.75 ×** the point count (923/1 232, 1 019/1 360,
+1 163/1 552, 59/80) — too consistent to be coincidence, and not explained.