Tie: the element layout differs by i16[3] high byte, and (6,7) is a real pair

Two results, one of them a correction.

1. "(6,7) is just the constant 4096/0 pair, not a texcoord" -- wrong. It looked
   like an artifact because a constant is trivially a pair of multiples of 4096.
   But partitioned by i16[3]'s high byte it is a genuine fixed-point pair in its
   own right:

     i16[3] high byte ZERO (n = 89,341)        divisor rate by slot pair
         pair         /1      /4     /16    /256
         ( 0, 1)   100.0%  11.5%   4.6%   3.3%   baseline
         ( 2, 3)   100.0%  11.0%   4.5%   3.3%   baseline
         ( 4, 5)   100.0%  92.9%  92.0%  91.8%   the texcoords
         ( 6, 7)   100.0%  89.5%  87.3%  86.5%   a SECOND fixed-point pair

   If (6,7) were a constant it would score 100%, not 89.5%. The constant is the
   common case WITHIN it, not the whole of it -- which is exactly the distinction
   the constant-artifact lesson is about, and I applied it backwards last time.

   So the ordinary element carries TWO fixed-point pairs, (4,5) and (6,7), with
   (0,1) and (2,3) at baseline. What (6,7)'s role is remains open -- second UV
   set, normal, or a zero-heavy fixed-point pair all fit.

2. The element LAYOUT differs between the three cases. Scoring all four slot
   pairs within the non-zero high-byte group, no pair stands out:

     i16[3] high byte NON-ZERO (n = 6,271)
         pair         /1      /4     /16    /256
         ( 0, 1)   100.0%   4.6%   3.5%   0.7%
         ( 2, 3)   100.0%   2.0%   0.6%   0.0%
         ( 4, 5)   100.0%   1.9%   0.3%   0.1%
         ( 6, 7)   100.0%   7.5%   5.7%   4.5%

   Best is 7.5% against a 2-5% baseline. So for those 6,271 vertices the 16 bytes
   are not laid out as position/texcoord/normal at all -- a different element
   shape, selected by the high byte.

This also explains why the global slot-pair score looked ambiguous to begin with:
pooling the two layouts averages a 92% pair and a 7% pair into one number that
describes neither. Fourth time this session that partitioning produced the answer
rather than merely bounding it.

docs/formats/core-data-regions.md

@@ -1774,6 +1774,27 @@ Within the all-zero case there is a third distribution: `i16[3] == 0` exactly
     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 element layout differs between those cases
+
+Scoring all four slot pairs within the non-zero high-byte group, **no pair
+stands out** -- the best is `(6,7)` at 7.5% for a divisor of 4, against a 2-5%
+baseline:
+
+    i16[3] high byte NON-ZERO (n = 6,271)
+        pair         /1      /4     /16    /256
+        ( 0, 1)   100.0%   4.6%   3.5%   0.7%
+        ( 2, 3)   100.0%   2.0%   0.6%   0.0%
+        ( 4, 5)   100.0%   1.9%   0.3%   0.1%
+        ( 6, 7)   100.0%   7.5%   5.7%   4.5%
+
+So for those 6,271 vertices the 16 bytes are **not laid out as
+position/texcoord/normal** at all -- none of the four pairs carries fixed-point
+coordinates. Whatever they are, it is a different element shape, selected by the
+high byte of `i16[3]`.
+
+This also settles why the global score looked ambiguous: pooling the two layouts
+averages a 92% pair and a 7% pair into one number that describes neither.
+
 **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
 now a field whose *role* is known, which is more than "packed word".