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/roadmap.md

@@ -290,6 +290,9 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 - [x] The tie **vertex element is 16 bytes**, measured over 95,612 vertices on
       levels 0-2 and settled by comparison: a 12-bit-fixed texcoord hit rate of
       **82.5%** at 16 bytes against 47.8% at 8 and 44.8% at 12.
+- [x] `i16[0..2]` are the **vertex positions**: LOD1/LOD2 of one class share 96.1%
+      of their position triples, while LOD1 of A against LOD2 of B shares 0.4% --
+      a factor of 240, asserted including the ratio. Axis order and scale unnamed.
 - [x] `i16[3]` is a **byte-sized index**, not a coordinate: 201 distinct values in
       `0..=254` inside the ordinary layout, whose high byte is the layout tag
       (93.4% of elements are `0x00`, 5.6% are `0x03`, 146 selector values in all).