re: record an open conflict with auto/regn-reader over the +0x10 base

That branch decodes REGN as a tetrahedral navmesh with strong checks and claims
the POF0 fixup base is chunk+0x10, so every offset on this page was read 16
bytes early.

I could not reproduce that on the one independently checkable thing here: the
plane list gives 133573/133573 unit normals at the unshifted base and 0/133573
at +16, and n.p+d = 0 holds to float round-off unshifted. A 16-byte shift
destroys it, so the blanket statement does not hold for this record.

Likely reconciliation is bookkeeping: a 48-byte face whose plane fields sit at a
different intra-record offset addresses the same bytes from a different origin.
That is a guess and I am not adopting either wording until checked.

Also confirmed: my own section-0 point test passes at 100% at BOTH bases, so it
never had power to distinguish them and should not be cited as validating the
offsets.

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

@@ -373,4 +373,43 @@ nothing rises above chance.
 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.
+twenty-first correlation.
+
+## ⚠️ Open conflict with `auto/regn-reader` over the `+0x10` base
+
+**2026-08-26.** Branch `auto/regn-reader` decodes `REGN` as a **tetrahedral
+navigation mesh** and reports the cell→geometry link solved, with strong checks
+(faces passing through 3 of 4 tet vertices, 253 722/253 722; portal cost equal to
+the distance between face centroids, 380 460/380 460). Its load-bearing structural
+claim is that the `POF0` fixup base is **`chunk + 0x10`**, and therefore that
+"every offset previously recorded on that page was read 16 bytes early" — offered
+as the reason the ~20 correlation tests on this page returned chance.
+
+**I could not reproduce that as stated, on the one thing here that is
+independently checkable.** Re-reading the plane list at both bases:
+
+| | records | unit normals |
+|---|---|---|
+| section at `chunk + offset` (what this page used) | 133 573 | **133 573 (100.00 %)** |
+| section at `chunk + 16 + offset` | 133 573 | **0 (0.00 %)** |
+
+And the plane identity `n·p + d = 0` holds to float round-off at the **unshifted**
+base. A 16-byte shift destroys it completely. So for *this* record the unshifted
+reading is right, and the blanket statement is not.
+
+🟡 **The likely reconciliation is bookkeeping, not disagreement.** The other
+branch describes a 48-byte **face** record whose plane fields sit at a different
+intra-record offset; `chunk+16` with the plane at `+0` addresses the same bytes as
+`chunk+0` with the plane at `+16`, which is exactly what this page uses. If so
+both readings are correct and only the origin convention differs — but that is a
+guess, and I am not adopting either page's wording until it is checked.
+
+**Also confirmed here, incidentally**: my section-0 point test passes at **100 %
+at both bases**, so it never had the power to distinguish them. That test could
+not have caught a 16-byte error and should not be cited as if it validated the
+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.