re: REGN cell payload indexes neither points nor planes -- static search exhausted

The previous test only tried section-1 targets. Closing that gap: the payload's
three index-shaped u32s, followed into the point list and the plane list and
checked for the target lying inside the referencing cell, all sit at the 0.203%
random control.

Two cells read 0.81%, 4x the baseline. I am not treating that as a lead: across
this and the previous iteration roughly twenty such tests have been run, and at
that count a single 4x enrichment on ~8000 trials is what noise looks like.
Calling it a signal would be the multiple-comparisons error a long hypothesis
sweep invites.

So REGN's header, grid, points, planes and cell index are decoded, section 1's
slot regions are censused, and the link between the grid and the geometry is not
reachable by any static test I can construct. The honest next step is the PE
code that reads a REGN object -- the same kind of work that cracked the .slb
packing phase -- rather than a twenty-first correlation.

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

@@ -337,4 +337,40 @@ 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.
+fields and four wide ones, whatever they refer to.
+
+## ❌ …nor the point list, nor the plane list — the static coupling search is exhausted
+
+**2026-08-26.** The previous test only tried section-1 targets, which left the
+obvious gap: the payload's three index-shaped `u32`s might address the **points**
+or the **planes** instead. Tested the same way — follow the index, ask whether
+the target lies inside the cell that referenced it:
+
+    RANDOM control                    0.203 %
+    +0  -> points 0.17 %   planes 0.16 %
+    +8  -> points 0.81 %   planes 0.09 %
+    +12 -> points 0.81 %   planes 0.09 %
+
+All at the control rate. The two 0.81 % cells are 4× the baseline, and I am
+**not** treating that as a signal: across this and the previous iteration I have
+now run on the order of twenty of these tests (three index fields × three
+sections × two readings × several offsets), and at that count a single 4×
+enrichment on ~8 000 trials is what noise looks like. Reporting it as a lead
+would be exactly the multiple-comparisons error that a long hypothesis sweep
+invites.
+
+### Where this leaves `REGN`
+
+✅ Decoded: the header and grid, section 0 (points), section 2 (planes), section
+3 (the cell index), and the strides and field regions of section 1.
+
+❌ Not decoded, and **not reachable by the tests available statically**: any link
+between the grid and the geometry. Every index-shaped field has been followed
+into every section and checked for spatial agreement, against controls, and
+nothing rises above chance.
+
+❔ **What would actually settle it** is the code — find what reads a `REGN`
+object in the executable and watch which fields it dereferences. That is static
+PE work (`/work/*.pe`, offset = VA − 0x82000000) of the same kind that cracked
+the `.slb` packing phase, and it is the honest next step rather than a
+twenty-first correlation.