re: the REGN cell index does not reference section 1 -- two powered tests

The natural coupling in a file with a uniform grid and a list of small volumes
is that the grid indexes the volumes. Tested by spatial agreement, it does not.

Test 1: every u16 in a cell's 32-byte payload, tried as a section-1 index and
checked for its centre lying inside the referencing cell. Every field sits at
the 0.138% random-control rate.

Test 2: every float triple in the payload, checked for lying inside its own
cell. 0.15-0.81%, also chance.

Recorded a worthless number from the same run rather than dropping it: those
triples lie inside the object's BOUNDING BOX in 100.00% at five different
offsets. The bbox spans the whole 500 km map so any mid-range triple passes, and
overlapping windows at +0 and +4 both scoring 100% is the tell -- a real field
would not survive a four-byte shift. Third time in this investigation that a
containment test against something large has produced a meaningless 100%.

Incidental and real: u32 slots at +0, +8 and +12 are below 0x10000 in 100% of
payload records while +4/+16/+20/+24 are in 11% and +28 never, so the record has
three index-shaped fields and four wide ones.

docs/re/structures/regn-map-grid.md

@@ -292,4 +292,49 @@ Stated as a reading, not a measurement; nothing here counts objects.
 
 ❔ Still open: what slots 8–11 index, and what the six pairs in 12–23 are. What
 this iteration removed is a wrong frame — the file is not a tree, so tree-shaped
-tests will keep returning nothing.
+tests will keep returning nothing.
+
+## ❌ The cell index does not reference section 1 — two powered tests, both negative
+
+**2026-08-26.** The obvious coupling in a file with a uniform grid and a list of
+small volumes is that the grid indexes the volumes. It does not, by the only
+test that could show it: **spatial agreement**.
+
+**Test 1 — the cell payload as indices.** For every occupied cell, read its
+32-byte payload record and try each `u16` in it as a section-1 index, then check
+whether that node's centre lies **inside the cell that referenced it**:
+
+    RANDOM control            0.138 %
+    +0    0.08 %      +2    0.18 %      +4    0.11 %      +8    0.08 %
+    +10   0.10 %      +12   0.08 %      +14   0.08 %      … 
+
+Every field sits at the chance rate. **Nothing points at section 1.**
+
+**Test 2 — the cell payload as coordinates.** 32 bytes is eight floats, so a
+position could be in there. Trying every float triple and asking whether it lies
+inside its own cell:
+
+    +0  0.81 %   +4  0.81 %   +8  0.15 %   +12  0.16 %   +16  0.26 %   +20  0.78 %
+
+Also chance.
+
+### ⚠️ And the tempting number in that table is worthless
+
+The same run reported those triples lie **inside the object's bounding box in
+100.00 %** of cases, at five different offsets. That looks like a decode and is
+not: the bbox spans the entire 500 km map, so *any* mid-range float triple
+passes, and overlapping windows starting at +0 and +4 both scoring 100 % is the
+tell — a real field would not survive being read at a four-byte shift. It
+measures the size of the box, not the meaning of the bytes. This is the third
+time in this file's investigation that a containment test against something
+large has produced a meaningless 100 %, so it is recorded rather than quietly
+dropped.
+
+❔ So the grid and section 1 have no demonstrated link, and how a cell reaches
+its geometry is unknown. What is now excluded: the cell payload holding
+section-1 indices, and holding cell-local coordinates.
+
+✅ Incidental, from the same sweep: `u32` slots at **+0, +8 and +12** of the
+payload record are below `0x10000` in **100 %** of records, while +4, +16, +20
+and +24 are in only 11 % and +28 never — so the record has three index-shaped
+fields and four wide ones, whatever they refer to.