re: resolved -- the REGN base is chunk+0x10 and my section-0 offsets were 16 bytes early

The other branch supplied concrete offsets: for 3506e972 its face record 0 and
its plane normal both begin at 0x1c700, and my chunk + offset_at_0x78 + 16 gives
0x1c700. Same bytes, different bookkeeping -- so the n.p+d result stands
unchanged and was never in dispute.

The base is chunk+0x10, on evidence with power: the loader does addi r3,r31,16;
at +0x10 the six POF0-relocated slots land exactly on 0x70-0x84, the six section
pointers, whereas at +0 they would relocate the u16 counts and leave two section
pointers unrelocated, which is non-functional; and section-0 record 0 reads as a
bbox corner at +0x10 and garbage at +0.

So my '13467/13467 points inside the bbox' was vacuous. Only 11 of 13467 read as
denormal at the wrong base -- the rest were still plausible coordinates, because
a 16-byte shift inside a packed array of f32 triples yields other floats from
the same array. Recorded the general form: a containment test cannot detect a
shift inside a homogeneous array, because the shifted values come from the same
distribution. For that class of error it is not a weak check, it is no check.

'Section 0 is a point list' happens to be right; the evidence I gave for it was
not evidence.

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

@@ -412,4 +412,53 @@ offsets.
 ❔ Until the conflict is resolved, treat the plane/face layout on this page as
 verified by its own arithmetic and the tetrahedral decode on `auto/regn-reader`
 as verified by its own — and do not merge the two offset conventions without
-re-running one check from each.
+re-running one check from each.
+
+## ✅ RESOLVED — the base IS `chunk + 0x10`, and my section-0 offsets were wrong
+
+**2026-08-26, same day.** The conflict above is settled, and it settles against
+me on the boundary while leaving the plane arithmetic intact.
+
+**The plane fields were never in dispute.** For object `3506e972`, the other
+branch's face record 0 begins at `0x1c700`, and its plane normal begins at the
+same address; my `chunk + offset_at_0x78 + 16` gives `0x1c700` too. **Same bytes,
+different bookkeeping** — exactly the reconciliation guessed above. The
+`n·p + d = 0` result stands unchanged.
+
+**The base is `chunk + 0x10`**, on evidence that has power where my tests did
+not:
+
+* the loader does it: `8246519c  addi r3, r31, 16`;
+* at `+0x10` the six `POF0`-relocated slots land exactly on `0x70`–`0x84`, the six
+  section pointers. At `+0` they would land on `0x60`–`0x74` — relocating the
+  `u16` **counts** and leaving two section pointers unrelocated. Not merely
+  wrong, non-functional;
+* section-0 record 0 reads as a bbox corner at `+0x10` and as garbage at `+0`.
+
+### ❌ And my point-list evidence was vacuous
+
+I reported "13 467/13 467 section-0 points lie inside the bbox" as the check that
+made section 0 a decode. Read at the correct base, record 0 of four objects is:
+
+    base +0    (1.4e-41, 5.3e-41, 0)      (2.2e-40, 2.7e-40, 0)
+    base +16   (-50000,-50000,-50000)     (-250000, 250000, -250000)
+
+So my offsets were 16 bytes early throughout. **Only 11 of 13 467 points read as
+denormal at the wrong base** — the rest were still plausible coordinates inside
+the box, because a 16-byte shift within a packed array of `f32` triples yields
+*other floats from the same array*. That is the general form of the failure and
+it is worth stating plainly:
+
+> **A containment test cannot detect a shift inside a homogeneous array.** The
+> shifted values are drawn from the same distribution as the correct ones, so the
+> test passes at 100 % either way. It is not a weak check — for this class of
+> error it is no check at all.
+
+The conclusion "section 0 is a point list" happens to be right. The evidence I
+gave for it was not evidence.
+
+✅ **Adopt `chunk + 0x10`.** The plane *fields* need no change; the record
+*boundary* moves, and the four integer words I described as "four zeros" move
+with it into the record they describe — which is where the face adjacency, and
+the answer to the cell→geometry question, was hiding. See branch
+`auto/regn-reader` for the tetrahedral decode.