Retract the tie vertex position claim; the stride is not 16

Task was to name the axis order and scale of the tie vertex positions by
fitting the class header's bounding sphere. The sphere does not exist: at
+0x30 those bytes are zero on every class. Scanning the header for
float-like words found +0x10, +0x14 and +0x18 (the LOD switch distances,
already named) and +0x40 on 1,676 of 1,864 classes, which is not a sphere.

What the run produced instead is a retraction. Dumping one packet's vertex
region raw shows the first 16 bytes are header material, not a vertex --
0x0000df20 is not a coordinate, and the words after it are the vif and
material words. A 16-byte group does recur at +64 and +128 with identical
structure, so the stride is not uniform: some elements are 4 bytes, some 16,
and the run length varies.

Two candidate bases were measured and neither clusters. With packet +
vert_ofs the per-class extents run median 64,976, p90 65,517; with class +
vert_ofs, median 55,213, p90 64,352. Both span the whole i16 range, where a
position triple in a class-local frame would span a fraction of it. The region
bounds are right -- vert_ofs + vert_size + scissor_size is the length -- it is
the element layout inside it that is wrong.

The i16[3] marker does not rescue it: bucketing every fourth element by the
marker's high byte gives markers 0, 0x48, 0xff and 0x01 with thousands of
vertices each, and only 0x48 shows a position signature (i16[1] extent 425
against 65,535 on the other two axes). The same marker 0 bucket spans all
three axes at full range, so the bucket does not select a layout.

The 95,612-vertex count and the 82.5% texcoord fixedness figure were computed
on the 16-byte reading and are now untested against the correct stride, which
is not yet known. The LOD1/LOD2-sharing test stays the strongest evidence for
positionality and is stride-insensitive.

docs/formats/core-data-regions.md

@@ -2500,6 +2500,53 @@ Neither of these decodes any record's *fields*. What is now settled is the
 shape the decoder has to handle: uniform stride per type, 4-byte aligned, with
 one named exception carrying three strides.
 
+## Tie: the "vertex positions" claim does not survive a stride test (2026-10-11)
+
+**Range measured:** level 0, one class, one 58-quadword packet region.
+
+The claim from earlier reads, `i16[0..2]` of a 16-byte element are the vertex
+positions, and 95,612 vertices were "measured" on that reading. A raw dump of
+one packet kills it:
+
+    0000df20  00900000  075006c0  094000c0
+    1f736c63  00544848  00281506  0d40001b
+    0d400a90  ffff00ff  00010ef0  80004253
+    4846a9e3  48a44001  47f40000  46d0b0de
+    0000ee50  00c00000  08a007e0  099000f0   <- group repeats at +64
+    0f807e72  01484848  00321208  0cf00017
+    0cf00ab0  ffff00ff  00020e60  80002e46
+    4858389a  48a44001  47f40000  46d7bbe3
+
+**The first 16 bytes are not a vertex at all** -- they are the packet's own
+header material: `0x0000df20` is not a coordinate and the following words are
+the vif/material words. The 16-byte group at +0 recurs at +64 and +128 with
+identical structure (a small i16, then 0, 0, then an index) and its three
+instances carry the values -8416, -4528, -784. So the stride is **not** 16
+throughout: some elements are 4 bytes, some 16, and the run length varies.
+
+**The period-4 marker does not generalise either.** Grouping every fourth
+16-byte element by the high byte of `i16[3]` gives marker 0 (n 9,204), 0x48
+(n 4,140), 0xff (n 4,912) and 0x01 (n 1,137), and only 0x48 shows a
+plausible position signature -- `i16[1]` extent 425 against `i16[0]` and
+`i16[2]` at 65,535, which is the height axis of a flat object. But the same
+marker 0 bucket has all three slots spanning the full `i16` range, so the
+bucket does not select a layout.
+
+**Two candidate vertex bases were measured and neither clusters.** With
+`packet + vert_ofs` the per-class extents run median 64,976 and p90 65,517;
+with `class + vert_ofs` they run median 55,213 and p90 64,352. Both span the
+whole `i16` range, whereas a real position triple in a level-class local frame
+must span a fraction of it. `vert_ofs + vert_size + scissor_size` is the
+region length, so the region bounds are right -- what is wrong is the element
+layout inside it.
+
+**Consequence for earlier claims, stated plainly.** The 95,612-vertex
+measurement and the 82.5% texcoord fixedness figure were both computed on the
+16-byte reading and are not superseded by this -- they are untested against the
+correct stride, which is not yet known. The LOD1/LOD2-sharing test
+(96.1% same class against 0.4% different) remains the strongest evidence that
+the first slots are positional, and it is insensitive to stride.
+
 ## Most of the chunk container is level-independent
 
 Comparing every chunk record against the same record index in the other 26