Tie vertex slot 3 is a byte-sized index, not a coordinate

Splitting the 95,612 elements of levels 0-2 by i16[3]'s HIGH byte, which is the
layout selector:

    0x00   89,341   93.4%
    0x03    5,344    5.6%
    144 other selector values   927    1.0%

146 selector values in all. Not a two-way switch, and the second case is not 0x01.

Inside the ordinary layout i16[3] is not a coordinate: 201 distinct values, all
within 0..=254, with 0 most common. That is an index. So the selector and the
index are not two independent halves sharing a slot -- it is one byte. The low
byte is the index, the high byte is the layout tag, and the ordinary layout never
sets the high byte. Asserted.

Nearly got this wrong twice, both times the same way, which is why they are in
the commit message:

1. The first pass gated the range on `w >= 0` instead of on `(w >> 8) == 0`,
   letting in the other layouts' large positive values. That reported "564
   distinct values in 0..=32664" -- a number that looks exactly like a
   coordinate and is really two populations unioned. The selector byte is the
   filter. The filter is part of the claim.

2. Two constants were guessed rather than measured (selector cardinality 159,
   and an upper bound that ignored non-ordinary layouts) and both were wrong.
   The cardinality is 146. Guessing a constant and then asserting it is how a
   measurement becomes a tautology.

Quantified the i16[6]/i16[7] question while I was in here, because "both are
multiples of 4096" has been sitting in the docs as a fixed-point signal:

    both %4096==0 in 86.5% of elements
    expected if the two residues were independent: 84.3%
    enrichment 1.0x -- exactly chance

They look like a fixed-point pair only because their dominant values, 4096 and 0,
are both multiples of 4096. Remove the constants and it is gone: 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 had already refused
to call that pair a texcoord for this reason; now the reason is a number.

Remaining slots in the ordinary layout, recorded: i16[0..2] read as position but
are unproven (10.7k-13.2k distinct each, full i16 range), i16[4]/i16[5] are the
texcoords, i16[6]/i16[7] unnamed.

Also fixes two clippy map_or lints and an import that a stray --fix had broken.
238 tests, clippy clean.

docs/formats/core-data-regions.md

@@ -1969,3 +1969,55 @@ Surveyed against the open items: no volume structures, no `TieTex`/tie vertex
 layouts, no `SBlk`/`DAW` record fields, no wavelet tables. Collision has the
 API but not the data. It is a guide to the code, not a replacement for reading
 it.
+
+## The tie vertex's selector byte, and what slot 3 is not
+
+`i16[3]` is called the layout selector because its **high** byte partitions the
+elements. Splitting the 95,612 elements of levels 0-2 by that byte:
+
+| high byte | elements | share |
+| --- | ---: | ---: |
+| `0x00` | 89,341 | 93.4% |
+| `0x03` | 5,344 | 5.6% |
+| the other 144 values | 927 | 1.0% |
+
+146 distinct selector values in all -- not a two-way switch but a long tail
+behind one dominant case, and the second case is not `0x01`.
+
+Inside the ordinary layout, `i16[3]` is **not a coordinate**:
+
+    distinct values    201
+    range              0 ..= 254
+
+201 distinct values inside a byte's range, with 0 the most common, is an index.
+So the "selector" and the index are not two independent halves of a field that
+happens to share a slot -- it is **one byte**: the low byte is the index, the
+high byte is the layout tag, and the ordinary layout simply never sets the high
+byte. Asserted in `tie_vertex_element_is_16_bytes_with_fixed_texcoords`.
+
+This was nearly measured wrong. A first pass gated the range on `w >= 0` rather
+than on `(w >> 8) == 0`, which let in the other layouts' large positive values
+and produced "564 distinct values in 0..=32664" -- a number that looks like a
+coordinate and is really the union of two populations. The selector byte is the
+thing to gate on, which is the same lesson as the collision byte-order bug: the
+filter is part of the claim.
+
+The remaining slots, all in the ordinary layout:
+
+| slot | distinct | range | reads as |
+| --- | ---: | --- | --- |
+| `i16[0..2]` | 10.7k-13.2k each | full `i16` | position, unproven |
+| `i16[3]` | 201 | `0..=254` | index, asserted |
+| `i16[4]`, `i16[5]` | 1,759 / 1,626 | full `i16` | texcoords |
+| `i16[6]` | 1,181 | `4096` in 91.8% | unnamed |
+| `i16[7]` | 226 | `0` in 88.9% | unnamed |
+
+`i16[6]`/`i16[7]` are **not** a fixed-point pair, and the "both are multiples of
+4096" score is an artifact worth naming: 86.5% of elements have both divisible by
+4096, against 84.3% expected if the two residues were independent -- an
+enrichment of **1.0x**, i.e. exactly chance. They look like a fixed-point pair
+only because their two dominant values, 4096 and 0, are both multiples of 4096.
+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.