Refine the tie texcoord finding: it is i16[3]'s HIGH byte that selects

The previous commit said i16[3] selects the texcoord encoding. That was right but
loose -- it is specifically the HIGH BYTE, and the low byte is a separate thing.

Grouped by the high byte across the same 95,612 vertices on levels 0-2:

  i16[3] high byte        n        % / 16      % / 256
  0x00                89,341        92.0%        91.8%
  0x03                 5,344         0.0%         0.0%
  0x04                    71         0.0%         0.0%
  0x40                    58         5.2%         0.0%
  0x02                    47         2.1%         2.1%
  0x19, 0x05, 0x20, ...  the remaining 73

A high byte of zero is the ordinary case -- 89,341 of 95,612, 93.4% -- at 92%.
EVERY other high byte scores at or near zero. The split is on the byte, not on the
value: i16[3] of 1 and of 771 differ only in the high byte and behave completely
differently.

Within the all-zero case there is a third distribution: i16[3] == 0 exactly (5,851
vertices) scores 62% at 16 and 61% at 256, against 92% for 1..255.

So three cases, selected by the high byte and then the low:

  high 0x00, low 0x00    5,851    a third distribution, 62% at 1/16
  high 0x00, low 1..255 83,490    the ordinary case, 92% at 1/4096
  high non-zero         6,271     0%, an encoding this reading does not see

The 6,271 matches the figure quoted last commit for "vertices using an encoding
this reading does not see", and the two group counts sum consistently with the
committed test's 95,612 -- so this refines the finding rather than changing it.

A measurement trap worth recording: the all-zero case is a SUBSET of high byte
0x00, so summing the per-high-byte groups double-counts it. An intermediate total
came out at 100,792 against the true 94,941 for those groups; the committed test's
figure is the one to trust.

docs/roadmap.md

@@ -293,14 +293,14 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       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**, which explains the residual.
-      Grouped across 95,612 vertices on levels 0-2: `1..63` and `64..255` score
-      92.7% and 92.3% 12-bit fixed, `== 0` scores 29.2% at 4,096 but **60.7% at
-      256** -- a third distribution -- and everything at 256 or above, or
-      negative, scores **0%** at both. The 87.3% of vertices in `1..255`
-      contribute exactly the 82.5% measured overall, so the residual is fully
-      accounted for. It is a field whose *role* is known even though its meaning
-      is not.
+- [x] `i16[3]` **selects the texcoord encoding**, and 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
+      and of 771 differ only in the high byte and behave completely differently.
+      Within the all-zero case, `i16[3] == 0` exactly (5,851) is a third
+      distribution at 62%. Three cases: `0x00/0x00`, `0x00/1..255`, and non-zero
+      high byte.
 - [ ] The remaining tie vertex **fields are not named.** `i16[0..3]` span the full
       `i16` range with 10,803-13,421 distinct values each. `i16[0..2]` are most
       likely position, but that is not established.