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

@@ -1747,8 +1747,32 @@ The remaining ~6% are **not 12-bit fixed at all**:
 
 **What this establishes:** `i16[3]` is a per-vertex packed attribute whose value
 *selects how the texcoord pair is stored*, rather than being an independent field
-sitting beside the texcoords. Values 1-255 are the ordinary case; 0 is special;
-256 and above, and negatives, are a different encoding entirely.
+sitting beside the texcoords.
+
+**Refined: it is the HIGH BYTE that selects.** 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, or **93.4%** --
+and it scores 92%. **Every** other high byte scores at or near zero. The split is
+on the byte, not on the value: `i16[3]` values 1 and 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
 
 **Not established:** what any of those three cases means. Whether `i16[3]` is a
 texture index, a normal index, a flag or a combination is still open -- but it is

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.