re: refute my own BVH reading of REGN section 1

Last iteration I offered 'position + scalar + integer links is the shape of a
BVH node' as a reading of the shape. Tested properly it fails.

Following every u16 half of every integer slot and checking child-sphere-inside-
parent-sphere gives 0.00% for every candidate -- but the informative number is
the RANDOM control, also 0.00%. No node's sphere contains any other node's
sphere anywhere in the file, so there is no nesting for an index to point at and
the hypothesis dies before the indices matter.

The reason is scale: slot 7 has a median of 3139 against a median inter-node
distance of 45457, 14x smaller, and a random other centre falls within it 0.40%
of the time. It is also smaller than the smallest grid cell on any map.

So slot 7 is a LOCAL scale, not a hierarchy radius. 63410 scattered centres each
with a sub-cell extent is the shape of many small independent volumes, which
would fit per-object collision hulls for asteroids and debris -- a reading, not
a measurement.

What this removes is a wrong frame: the file is not a tree, so tree-shaped tests
will keep returning nothing.

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

@@ -249,4 +249,47 @@ promoting it.
 ❔ So section 1 stays open. What would settle it is a test with power: pick a
 record, follow a candidate index, and check that the thing it lands on is
 spatially consistent with that record's own position and radius. That needs the
-tree walked, not the fields counted.
+tree walked, not the fields counted.
+
+## ❌ The BVH reading is refuted — and slot 7 is a *local* scale
+
+**2026-08-26.** Last iteration I wrote that "position + positive scalar +
+integer links is the shape of a bounding-volume hierarchy node", explicitly as a
+reading of the shape. Tested with a design that has power, it fails.
+
+**The containment test.** If slots 8–11 hold child indices, a child's sphere
+should sit inside its parent's. Following every `u16` half of every integer slot
+and checking `|C_child − C_parent| + R_child ≤ R_parent` (2 % slack):
+
+    RANDOM control                   0 of 126 787  =  0.00 %
+    slot 8 half 0    63 389 tried    0.00 %
+    slot 8 half 1    63 395 tried    0.00 %
+    …every candidate…                0.00 %
+
+**The random control is the informative row.** It is also 0.00 %, which means no
+node's sphere contains any other node's sphere *anywhere in the file* — so there
+is no nesting for an index to point at, whatever the indices mean. The
+hypothesis fails before the indices are even in question.
+
+**Why**: slot 7 is far too small to bound neighbours.
+
+| | median | p10 | p90 |
+|---|---|---|---|
+| slot 7 | **3 139** | 1 965 | 9 275 |
+| pairwise centre distance | **45 457** | 19 071 | 126 295 |
+
+Slot 7 is **14× smaller** than the typical distance between nodes, and a random
+other centre falls within it only **0.40 %** of the time. It is also smaller
+than the smallest grid cell on any map (10 000).
+
+So ✅ **slot 7 is a local scale, not a hierarchy radius** — sub-cell sized, with a
+narrow spread. Together with 63 410 scattered centres across a 500 km cube, that
+is the shape of **many small independent volumes**, not a tree.
+
+🟡 That fits per-object collision volumes — a map's asteroids and debris, which
+the mission `Route` tables independently show as `Frame_S<NN>_Asteroid` records.
+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.