The tie vertex element is 16 bytes and the layout cycles; correct e5cd3df

Picking up after e5cd3df, which retracted the 16-byte tie vertex element for
want of a detectable stride. There is one, at 64 bytes, and it beats a shuffle
control by a factor of ten:

    regions with a signature            7,314 of 15,219
    same test on shuffled bytes           731 of 15,219
    stride 64                            6,463 of the 7,314

Range: every tie vertex region on all 27 levels, 15,219 regions. A byte offset
counts as constant at stride s when every unit of length s agrees there, with
at least three units, an exact divide, and at least eight constant bytes.

Dumping the regions shows four *different* 16-byte layouts repeating at
+00 +10 +20 +30: one is a small i16 followed by two zeroes, one carries 255,-1
mid-element, the other two carry neither. So the element is 16 bytes and the
layout cycles with period four. That is a partial retraction of a retraction:
e5cd3df was right that the four layouts differ, and right that pooling them
spans the whole i16 range. It was wrong to conclude that 16 is not the stride.

Four tests still do not separate the four layouts, and the table records all
four because the negative is the finding: LOD1/LOD2 sharing is 16.1/16.2/16.2/
16.3 percent across the four groups, f32-in-band is 23 percent in all four
(which is what uniform random gives), and i32-in-band is 0/2/6/0. The position
stays unnamed.

Also clears the clippy warnings that had accumulated on main from the disassembly
work: doc_lazy_continuation on three prose blocks, two negated-comparison guards
in gs.rs, a doc-then-item blank line twice over, a useless usize::from, and an
as_chunks that needs 1.88 while the workspace declares 1.85 -- replaced with
chunks_exact rather than moving the MSRV.

Clippy is clean. Suite with the disc: 67 disc tests, 156 gc-formats, 22
gc-trace, 23 gc-engine, 19 gc-game; without it, 67 disc tests skip early and
report the same count.

docs/formats/core-data-regions.md

@@ -3399,8 +3399,10 @@ some byte offset is constant across every unit.
     stride 48                            12
     stride 16                             3
 
-**64 bytes, not 16, wherever a stride is detectable** -- and for more than three in
-five regions there is no stride in range that produces a single constant byte.
+**64 bytes, not 16, wherever a stride is detectable** -- which is now read the
+other way round. The 64 bytes are **four 16-byte elements with four different
+layouts**, cycling `+00 +10 +20 +30`. So 16 *is* the element size, and 64 is the
+period of the layout. The corrected measurement is below.
 Those regions are genuinely variable, or the element is larger than the region
 divided by sixteen units, which is the same statement.
 
@@ -3426,12 +3428,62 @@ imprecise, it was reporting the artefact.
 64 is the stride where one is detectable, which is not the same as the stride.
 For the 1,139 regions with no constant byte under any tested stride, the element
 is still unknown, and the tie vertex layout remains open. What is settled is that
-**16 is not it** -- only 3 of 1,844 regions show a constant byte at 16 -- which is
-the quantitative version of the retraction, and a third independent measurement
-now agreeing with it.
+**no single layout describes every element** -- and the retraction that followed
+was itself half wrong, because it read "16 is not the stride" where the data
+says "16 is the element and the layout cycles".
 
 
-## Attempting the moby_anim unblock: the class header, and where it stalls
+## Corrected: the 64-byte period is four layouts, and it beats a shuffle control
+
+The retraction in `e5cd3df` said the 16-byte element reading does not survive a
+stride test. It survives one; the stride just was not being looked for properly.
+
+**Range measured:** every tie vertex region on all 27 levels, **15,219 regions**.
+
+A byte offset is *constant at stride `s`* when every unit of length `s` agrees
+there. Requiring at least three units, a stride that divides the region exactly,
+and at least eight constant bytes:
+
+    regions with a signature          7,314 of 15,219
+    same test on shuffled bytes         731 of 15,219
+    stride 64                          6,463 of the 7,314
+
+**The signature is ten times the control**, so it is a property of the data and
+not of the test. Dumping the regions that carry it shows four *different*
+16-byte layouts repeating at `+00 +10 +20 +30`: one is a small i16 followed by
+two zeroes, one carries `255, -1` mid-element, and the other two carry neither.
+So **the element is 16 bytes and the layout cycles with period four**.
+
+This is a partial retraction of a retraction, recorded as such. What `e5cd3df`
+correctly established is that the four layouts are not the same, and that its
+extents spanned the whole `i16` range because it pooled four layouts into one
+set -- rule 3a's failure arriving through a different door. What it wrongly
+concluded is that 16 is not the stride.
+
+### What still does not identify the position
+
+Four tests were run against the four layouts and **none separates them**:
+
+| test | group 0 | group 1 | group 2 | group 3 |
+|---|---|---|---|---|
+| LOD1/LOD2 triples shared, same class | 16.1% | 16.2% | 16.2% | 16.3% |
+| words as `f32` in `1e3..1e7` | 23% | 23% | 23% | 23% |
+| words as `i32` in `1e6..1.6e6` | 0% | 2% | 6% | 0% |
+| `f32` finiteness | 99% | 77% | 99% | 99% |
+
+The `f32` and `i32` rates are what uniform random gives -- those two rows carry
+their own control -- and the LOD1/LOD2 sharing is the same in every group to
+within a fifth of a point. Four measurements agreeing this closely say the four
+groups are one population for these statistics, not that any of them is a
+position. The position remains unnamed, and the `i16[0..2]` claim stays
+retracted; it is just retracted for a different reason than the one recorded at
+the time.
+
+`tie_vertex_region_has_a_stride_64_period` asserts the three bounds above, plus
+the shuffle margin, so a claim that the period is not 64 fails rather than
+sailing through.
+
+## Attempting the moby_anim unblock: the class header, and where it stalls## Attempting the moby_anim unblock: the class header, and where it stalls
 
 `MobyInstance` names `animSeq`, `animLayers`, `jointCnt` and `jointCache` as
 runtime pointers. Those pointers are useless on the disc -- they are RAM