re: REGN sections 0/1/2 have strides, and section 2 is a plane list

The three sections recorded as undecoded are fixed-stride arrays and counts[0..2]
are their record counts: 12, 96 and 48 bytes. Section 1's remainder is exactly 0
in 11/11 objects and section 2's exactly 96 in 11/11, which is what makes these
strides rather than a coincidence of division.

Section 0 is a point list: 13467 of 13467 records lie inside their object's own
header bounding box.

Section 2 is a plane list, 12 f32: four zeros, a unit normal (|n|=1 in
133573/133573), a signed distance, a point inside the bbox (133573/133573), and
a trailing 1.0 (133573/133573). The decisive check is algebraic -- n.p + d must
vanish for a real plane, and over all 133573 records the relative residual has a
median of 2.29e-08 and a maximum of 2.15e-07. That is float round-off, not a fit.

So a REGN object carries a point list and a plane list beside its uniform grid,
which fits collision or region-boundary geometry and sits next to MCOL.

Still open: section 1 (96 B, 60631 records), what queries the planes, the zeros
at [0..3], and the constant 96-byte tail.

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

@@ -143,3 +143,61 @@ So `.rgn`/`REGN` is stage navigation/path data referenced by the stage record,
 and `.col`/`MCOL` is the stage collision mesh. This does not by itself validate
 either of the two refuted cell-payload readings recorded above, but it does
 explain why the payload looks like a grid of route data.
+
+
+## ✅ Sections 0, 1 and 2 have record strides — and section 2 is a PLANE list
+
+**2026-08-26.** The three sections the page called undecoded are fixed-stride
+record arrays, and `counts[0..2]` are their record counts. Dividing each
+section's byte span by its count over all 11 objects:
+
+| section | stride | evidence |
+|---|---|---|
+| 0 | **12 bytes** | `count × 12` fits with a remainder of 0–12 in **11 / 11** |
+| 1 | **96 bytes** | `count × 96` fits with a remainder of **exactly 0 in 11 / 11** |
+| 2 | **48 bytes** | `count × 48` fits with a remainder of **exactly 96 in 11 / 11** |
+
+Section 1 landing on a zero remainder in every object, and section 2 on the same
+96-byte tail in every object, is what makes these strides rather than a
+coincidence of division.
+
+### ✅ Section 0 is a point list
+
+12 bytes is three `f32`. Over **13 467** records across all 11 objects, **every
+one lies inside that object's own header bounding box — 13 467 / 13 467 (100 %)**.
+Values land on the box corners (`±250 000`) and inside.
+
+### ✅ Section 2 is a plane list — 48 bytes, and the plane equation closes
+
+Read as twelve `f32`:
+
+    [0..3]   zero
+    [4..6]   unit normal          |n| = 1 ± 0.02 in 133 573 / 133 573 (100 %)
+    [7]      signed distance d
+    [8..10]  a point on the plane, inside the bbox in 133 573 / 133 573 (100 %)
+    [11]     1.0 exactly           in 133 573 / 133 573 (100 %)
+
+**The check that makes this a decode**: for a genuine plane, `n·p + d` must be
+zero. Over all **133 573** records:
+
+    |n·p + d| / scale :  median 2.29e-08   p90 6.78e-08   max 2.15e-07
+
+That is float round-off, not a fit — the relation holds to the last bits of a
+32-bit float in **every record on the disc**. Three independent 100 % properties
+(unit normal, point in bbox, trailing 1.0) and an exact algebraic identity are
+well past what a wrong reading survives.
+
+So a `REGN` object carries, alongside its uniform grid, a **point list** and a
+**plane list** — which is the shape of collision or region-boundary geometry,
+and consistent with `MCOL` sitting beside it.
+
+### ❔ Still open
+
+* **Section 1** (96 bytes/record, 60 631 records disc-wide) is untouched. Its
+  content is float-dominated with both large coordinates and mid-range values.
+  96 bytes is 24 floats — a plausible shape for a 4×4 matrix plus extras, or for
+  two 48-byte plane records, but nothing is measured.
+* **What the planes are for.** "Collision or region boundary" is a reading of the
+  shape; nothing here shows what queries them.
+* The **zeros at `[0..3]`** of every plane record, and the constant `96`-byte
+  tail after section 2, are unexplained.