Retract the tie texcoord field: a dominant-value artifact, one level down

Picked the tie flat encoding to close, since e5cd3df left it as the largest
unidentified field. What came out was a retraction of my own earlier claim.

The texcoord slot was recorded at i16[4]/i16[5] on a 73.6% "both multiples of
4096" score. Two problems, either of which would be enough.

First, that 73.6% was computed on the 16-byte element reading that e5cd3df
retracted. Half the records are VIF packets and half are flat, so the figure
describes neither population cleanly.

Second, and decisive on its own: measured on the FLAT records only -- levels 0-2,
930 records, 47,909 vertices -- the question that separates a 12.4 fixed-point
texcoord from anything else is how many of a slot's distinct values are multiples
of 4096 at all. For a texcoord it is all of them.

    slot        distinct   of which are multiples of 4096
    i16[4]         1,488      16
    i16[5]         1,261      16
    i16[6]           966       4
    i16[7]           489       5

One percent. The dominant PAIRS do look like UV corners -- (0,0) 5,773,
(0,4096) 5,500, (4096,4096) 5,059, (4096,0) 4,521 -- and that is precisely why
the claim was persuasive. But it is a statement about the most frequent values,
not about the field: 1,472 of the 1,488 values in i16[4] are not multiples of 4096
at all.

This is the moby class-ID artifact one level down. A small set of dominant values
that happen to satisfy the test, scored as though the whole population did. The
arithmetic was right about the popular values and the conclusion was wrong about
the field. The retraction commit itself warned about exactly this shape, which
makes the repeat more useful than the original claim was.

So the texcoord slot of a flat tie record is NOT identified. What survives is the
boundary work -- vert_ofs + vert_size + scissor_size is the region length -- and
the LOD1/LOD2 sharing result, which is stride-insensitive and survives the stride
retraction.

Both docs updated: the roadmap's two [x] claims about the texcoord field and about
i16[3] selecting its encoding are now [~] with the evidence, and the format file
has a retraction section giving the table above.

I did not find a replacement reading for i16[4..7]. Three discriminators were
tried -- LOD sharing, multiple-of-4096 rate, value-set size -- and each came back
ambiguous or negative. That is worth recording as the state rather than
generating a fourth hypothesis.

258 tests.

docs/roadmap.md

@@ -315,12 +315,26 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       `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).
       Asserted.
-- [x] The tie **texcoord field is located**: `i16[4]`/`i16[5]` of the 16-byte
+- [~] The tie **texcoord field is no longer located.** It was recorded at
+      `i16[4]`/`i16[5]` on a 73.6% "both multiples of 4096" score, but that score
+      is contaminated twice over: it was computed on the 16-byte reading that
+      `e5cd3df` retracted, and measured on all records rather than the flat ones.
+      Restricted to the **flat** records, and asking the discriminating question
+      -- how many of the slot's distinct values are multiples of 4096 at all --
+      gives **16 of 1,488** for `i16[4]` and 16 of 1,261 for `i16[5]`. A 12.4
+      fixed-point texcoord would be *all* of them. The dominant values do look
+      like UV corners (`(0,0)`, `(0,4096)`, `(4096,4096)`, `(4096,0)`), which is
+      why it read as convincing; that is a statement about the most frequent
+      values, not about the field -- the same shape as the 305x class-ID
+      artifact. The texcoord slot in a flat tie record is **not identified**.
+      The earlier note it supersedes read: `i16[4]`/`i16[5]` of the 16-byte
       element, scoring 73.6% for 12-bit fixedness over 36,501 level-0 vertices,
       against 1.1% for `(0,1)` and 4.8% for `(2,3)`. The `(6,7)` pair scores
       *higher* at 76.6% and is **not** a texcoord -- it is the near-constant
       `4096, 0` pair, which is trivially two multiples of 4,096.
-- [x] `i16[3]` **selects the texcoord encoding**, and it is specifically the
+- [~] `i16[3]` was recorded as selecting the texcoord encoding; that rested on
+      the same 16-byte reading and is withdrawn with it. See the note above.
+      The original text read: it is specifically the
       **high byte**. Grouped across 95,612 vertices on levels 0-2: high byte `0x00`
       covers 89,341 vertices (93.4%) at 92% 12-bit fixed, while **every** other
       high byte scores 0%. The split is on the byte, not the value -- `i16[3]` of 1