Establish the tie vertex element is 16 bytes, and correct the roadmap's tie entry

With TieRecord identified as RAC1's TiePacketHeader, each record's leading word
points at its packet in the block payload. Following it and stepping vert_size
elements from vert_ofs reaches the vertices: 95,612 of them on levels 0-2.

Element size settled by comparison, not assumed. Requiring the texcoord pair to be
12-bit fixed -- both words multiples of 4096, which is how 0x1000 = 1.0 reads:

  element 16 bytes : 78,919 / 95,612 = 82.5%
  element  8 bytes : 45,661 / 95,612 = 47.8%
  element 12 bytes : 44,834 / 95,612 = 44.8%

Sixteen wins by a factor of 1.7 over the nearest alternative.

Observed layout, 8 x i16: the first three slots span the full i16 range with
10,803-13,421 distinct values each; i16[4] and [5] are the texcoords and are both
multiples of 4096 on 82.5%; i16[6] reads 4096 on 85.8% and i16[7] reads 0 on
84.0%.

Not established: what any field means, and why the texcoord rate is 82.5% rather
than 100%. The residual tracks record shape -- (shaders 2, control 7, size 2)
hits 60%, (shaders 1, control 18, size 5) hits 89% -- so it is not one bad block
but something per-packet this reading does not capture.

Worth recording that this is the OPPOSITE of what the disc alone concluded two
commits ago. Reading the header word at +0x00 as an element count gave 0 of 922
blocks dividing; it is the byte offset to the payload, so the table it bounds has
16-byte records. The number was right and the reading was wrong, which is what
the packet-header identification corrected.

The roadmap's tie entry was also stale -- it still said "a 16-byte record is
withdrawn", which the packet-header work had already reversed. Rewritten from the
commits: both indirections, self-delimiting blocks, the TiePacketHeader
identification with its 15,219/15,219 rule, the 16-byte vertex element, and what
remains open. A test asserts the element size against both alternatives so the
82.5% figure cannot be quietly replaced by an assumption.

docs/formats/core-data-regions.md

@@ -1587,3 +1587,41 @@ disproved rather than left as guesses:
 So the record has one more field than the loader note claimed, the disc's
 offset table is two bytes late relative to it, and what it counts is the next
 question -- with the entry-count reading now out of the way.
+
+## The tie vertex element is 16 bytes
+
+With `TieRecord` identified as R&C1's `TiePacketHeader`, each record's leading
+word points at its packet in the block payload. Following it and stepping
+`vert_size` elements from `vert_ofs` reaches the vertices.
+
+**Range measured: 95,612 vertices** on levels 0-2.
+
+**Element size, settled by comparison rather than assumed.** Requiring the
+texcoord pair to be 12-bit fixed -- both words multiples of 4,096, which is how
+0x1000 = 1.0 reads -- gives:
+
+    element 16 bytes : 78,919 / 95,612 = 82.5%
+    element  8 bytes : 45,661 / 95,612 = 47.8%
+    element 12 bytes : 44,834 / 95,612 = 44.8%
+
+Sixteen wins by a factor of 1.7 over the nearest alternative, so it is the
+element size.
+
+**Observed layout**, 8 x `i16`:
+
+    i16[0..3]   10,803 to 13,421 distinct values, spanning the full i16 range
+    i16[4], [5] the texcoords; both multiples of 4,096 on 82.5% of vertices
+    i16[6]      reads 4,096 on 85.8%
+    i16[7]      reads 0 on 84.0%
+
+**Not established:** what any of the eight fields *means*, and why the texcoord
+rate is 82.5% rather than 100%. The residual varies with record shape -- records
+with `(shaders 2, control 7, control_size 2)` hit 60%, `(shaders 1, control 18,
+control_size 5)` hit 89% -- so it is not one bad block but something that varies
+per packet, possibly a second texcoord encoding for records that need it.
+
+Recorded because the 16-byte answer is the *opposite* of what the earlier
+commit concluded from the disc alone. Reading the header word at `+0x00` as an
+element count gave 0 of 922 blocks dividing; it is the byte offset to the payload,
+so the table it bounds has 16-byte records. The number was right and the reading
+was wrong, which is the error the packet-header identification corrected.