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/formats/core-data-regions.md

@@ -1705,7 +1705,7 @@ fixedness over 36,501 level-0 vertices locates the fields:
 
     (i16[0], i16[1])    1.1%   not a texcoord
     (i16[2], i16[3])    4.8%   not a texcoord
-    (i16[4], i16[5])   73.6%   <- the texcoords
+    (i16[4], i16[5])   73.6%   <- SCORED as the texcoords; see the retraction below
     (i16[6], i16[7])   76.6%   <- the near-constant 4096/0 pair
 
 **`(6,7)` scores higher and is not a texcoord.** It is the near-constant
@@ -2800,3 +2800,42 @@ coordinate produces in 12.4 fixed point, which is where the earlier texcoord
 reading came from and why it looked convincing on the records that are flat.
 
 Asserted in `tie_vertex_regions_split_between_vif_and_flat`.
+
+
+## RETRACTED: the tie texcoord field is at `i16[4]`/`i16[5]`
+
+The 73.6% figure above, and the claim that slot pair is the texcoord, do not
+survive. Two separate problems.
+
+**It was measured on a reading that has since been retracted.** The 73.6% was
+computed across all records at a 16-byte element stride. `e5cd3df` established
+that the stride is not 16 -- half the records are VIF packets and half are flat --
+so the numbers describe neither population cleanly.
+
+**And on the flat records, the fixed-point reading fails.** 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.
+Measured on the **flat** records only, levels 0-2, 930 records and 47,909
+vertices:
+
+    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 exactly
+why the claim was persuasive. But it is a statement about the most frequent
+values, not about the field, and 1,472 of the 1,488 values in `i16[4]` are not
+multiples of 4096 at all.
+
+This is the same failure shape as 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 73.6% is the arithmetic being right about the
+popular values and the conclusion being wrong about the field.
+
+So: on a flat record, `i16[4]`/`i16[5]` are **not identified**, and the texcoord
+slot of a tie vertex is unknown. What survives from the original section is the
+boundary work -- `vert_ofs + vert_size + scissor_size` is the region length -- and
+the LOD1/LOD2 sharing result, which is stride-insensitive.