Tie i16[0..2] are the vertex positions, with a control in the test

The three slots ahead of the index were "unproven position" for want of a test
that could fail. One is available on the disc alone, with the control built in.

LOD 1 and LOD 2 of a tie class are the same object at two levels of detail, so
anything that locates a vertex in that object's own geometry is shared between
the two blocks; a different class' LOD is an unrelated object. Intersecting the
sets of i16[0..2] triples both ways turns "is this a position" into a
measurement. Levels 0-5, ordinary-layout elements only:

    same class, LOD1 vs LOD2      96.1%   107 classes, 107 nonzero
    different class, control       0.4%   2,144 pairs

A factor of 240. Per level the same-class figure runs 94.4 / 97.9 / 98.1 / 96.7 /
96.8 for levels 0-4. The control stays under 1.0% except for one level-1 pair at
45.9% -- two classes sharing most of their geometry, which is what duplicate or
variant models should look like. Reported, not excluded, and the assertion is on
the mean rather than the max so it does not have to be.

Asserted in tie_vertex_slots_0_to_2_are_shared_positions, including the ratio
(same > 20 * diff) so a change that collapsed both numbers fails rather than
passing twice, and a nonzero-overlap check so no class can silently stop
agreeing with itself.

What this rules out is the point. An index, a handle or a per-vertex counter
would not be shared at 96% between two independently built LOD meshes, nor sit at
0.4% between two objects. With 10.7k-13.2k distinct values per slot over the
full i16 range, these are positions in the object's own frame. Scale and axis
order stay unnamed -- nothing here says centimetres, and axis order is
unconstrained because nothing here assumes one.

Two things worth recording about the process:

1. The diagnostic line printed "1.0%" for 99.4% because the format was
   `{same:.1}%` with no `* 100`. The assertions compared fractions and were
   always correct; only the readout was wrong. Same family as everything else in
   this log -- the readout disagreeing with the claim.

2. Inserting the new test in front of an existing one stranded that test's
   #[test] on my doc comment, which silently unregistered
   tie_vertex_element_is_16_bytes_with_fixed_texcoords. It showed up as
   "never used" in clippy, not as a missing test. Restored; both tie vertex
   tests are registered and 239 tests run.

Element layout now reads:
  +0x00 i16[0] position x     +0x06 u8 index 0..=254
  +0x02 i16[1] position y     +0x07 u8 layout tag, 0 in 93.4%
  +0x04 i16[2] position z     +0x08 i16[4] texcoord u
  +0x0a i16[5] texcoord v     +0x0c/+0x0e i16[6], i16[7] unnamed

docs/formats/core-data-regions.md

@@ -2021,3 +2021,57 @@ Strip the constants and the rest is not: of the 7,316 elements where `i16[6]`
 differs from 4096, only 36.7% are still multiples, and of the 9,905 where
 `i16[7]` differs from 0, **one** is. The disc test already refused to call it a
 texcoord for this reason; that caution is now quantified.
+
+## `i16[0..2]` are the vertex positions
+
+The three slots ahead of the index were "unproven position" for want of a test
+that could fail. There is one available on the disc alone, with a built-in
+control.
+
+**LOD 1 and LOD 2 of a tie class are the same object at two levels of detail.**
+Anything that locates a vertex in that object's own geometry is therefore shared
+between the two blocks, while a *different* class' LOD is an unrelated object.
+So: intersect the sets of `i16[0..2]` triples, same class versus different
+class, and if positions are what is in those slots the first number should be
+large and the second should be at zero.
+
+Levels 0-5, ordinary-layout elements only:
+
+    same class, LOD1 vs LOD2      96.1%   over 107 classes, 107 of them nonzero
+    different class, control       0.4%   over 2,144 pairs
+
+A factor of 240. Per level the same-class figure runs 94.4% (level 0), 97.9%
+(1), 98.1% (2), 96.7% (3), 96.8% (4), and the control never exceeds 1.0% except
+for one level-1 pair at 45.9% -- two classes in that level sharing most of their
+geometry, which is what duplicate or variant models should look like, and is
+reported rather than excluded.
+
+Asserted in `tie_vertex_slots_0_to_2_are_shared_positions`, including the
+separation ratio (`same > 20 * diff`) so a change that collapsed both numbers
+would fail rather than pass twice.
+
+What this rules out is the important part. An index, a handle, or any per-vertex
+counter would not be shared at 96% between two independently built LOD meshes, and
+would not sit at 0.4% between two objects. Combined with 10.7k-13.2k distinct
+values per slot across the full `i16` range, `i16[0..2]` are a position in the
+object's own frame. The *scale* and the axis order remain unnamed -- nothing here
+says whether these are centimetres, and the axis order is unconstrained because
+nothing here assumes one.
+
+The element now reads:
+
+    +0x00  i16[0]   position x        (unproven axis order and scale)
+    +0x02  i16[1]   position y
+    +0x04  i16[2]   position z
+    +0x06  u8       index, 0..=254
+    +0x07  u8       layout tag, 0 in 93.4% of elements
+    +0x08  i16[4]   texcoord u
+    +0x0a  i16[5]   texcoord v
+    +0x0c  i16[6]   unnamed
+    +0x0e  i16[7]   unnamed
+
+One caveat worth keeping visible: a test that prints a fraction with `{:.1}%`
+and forgets the `* 100` reports "1.0%" for 99.4%. That happened here, in the
+diagnostic line only -- the assertions compare fractions and were always right --
+but it is the same family of error as everything else in this log: the readout
+disagreeing with the claim.