re: MCOL A->B is 1:1 with count 1, matching REGN's cell-index convention

Filtering array A by the cell-index criteria and following each pointer: every A
record points at a distinct B record, 11/11, and every A count field is exactly
1, 11/11. Per object the A-record count is the number of occupied cells (110 to
575) and the counts sum to it exactly.

That is the same design REGN uses -- the corpus already records 'every occupied
cell has count exactly 1' there. Two sibling formats, one convention, and a
further independent confirmation of the A reading since the filter and the
cardinality are unrelated criteria.

Array B resisted, and both attempts failed in ways worth recording. The record
boundary was off by 8 again, producing records that start with the tail of the
previous structure -- the same mistake as the 0x74 check two iterations ago. And
the u16-index test had no power: the 0x5C block holds ~1232 points, so 'is this
u16 below the point count' passes for almost any small value, and duly reported
100% at seven offsets. Fourth time in these two formats that a bound-check
against a large collection produced a meaningless 100%.

Recorded what would have power instead: B records are 1:1 with occupied cells
and A carries that cell's bounding sphere, so a B field can be tested for
spatial consistency with that specific cell.

docs/re/structures/mcol-collision.md

@@ -149,4 +149,43 @@ Worth noting the split was crude — "first half by address", giving 2 509 vs
 partition that isolates a perfect population is stronger evidence than a careful
 one that isolates a good-ish population.
 
-❔ Array B's layout is still unread. That is the next thing.
+### ✅ A → B is one-to-one, and every count is 1
+
+Filtering array A by the cell-index criteria (so only genuine A records) and
+following each one's pointer, over all **11** objects:
+
+| | |
+|---|---|
+| every A record points at a **distinct** B record | **11 / 11** |
+| every A record's count field is **exactly 1** | **11 / 11** |
+
+Per object the A-record count is the number of **occupied cells** — 110, 118,
+117, 488, 488, 575, 514, 468, 492, 546, 572 — and the total of the count fields
+equals it exactly.
+
+That is the *same* design `REGN` uses: this corpus already records for `REGN`
+that "every occupied cell has count exactly 1 — total items equals occupied
+cells". Two sibling formats, same cell-index convention. It is a further
+independent confirmation of the A-record reading, since the filter and the
+cardinality are unrelated criteria.
+
+### ❌ Array B resisted a first pass, and the tests I reached for were bad ones
+
+I could not read B's record layout this iteration, and both attempts failed in
+ways worth recording rather than retrying:
+
+* **The boundary was off by 8 again.** Dumping from `pointer − 8` (as A's layout
+  needed) produced records that begin with what is plainly the *tail* of the
+  previous structure — a zero and `0x47295092`, the same radius value A's first
+  record carries. Same mistake as the `0x74` check two iterations ago.
+* **The `u16`-index test had no power.** The `0x5C` block holds ~1 232 points, so
+  "is this `u16` below the point count" is satisfied by almost any small value —
+  and duly reported 100 % at seven different offsets. That is the *fourth* time
+  in this pair of formats that a bound-check against a large collection has
+  produced a meaningless 100 %.
+
+❔ So B's layout is open. **What would have power**: B records are 1:1 with
+occupied cells and A already carries the cell's bounding sphere, so a candidate
+field in B can be tested by whether it is spatially consistent with *that
+specific cell* — the same design that worked for `REGN`'s faces, and the same
+design that these two bound-checks lack.