Show shrub packet records are two tagged 8-byte halves, fixed length

Range measured: level 0, the 1636 sixteen-byte records following the header
across all 29 packets. Per-byte distinct counts, not pooled.

Method: count distinct values and zero frequency at each of the 16 positions,
then tabulate the joint distribution of the two low-entropy positions.

Result: fourteen positions are uniformly varied, 101 to 153 distinct values,
zero in 13% to 58% of records. Two are not:

  byte 7   4 distinct: 0 (1432), 0x30 (135), 0x6d (40), 0x80 (29)
  byte 15  2 distinct: 0 (1618), 0x6d (18)

Both sit in the last byte of an 8-byte half, eight bytes apart, and both take
values from a small closed vocabulary rather than the full byte range. The
joint distribution shows no record where both are non-zero, and 0x6d appears in
either position but never both:

  (0,0) 1414   (0,0x6d) 18   (0x30,0) 135   (0x6d,0) 40   (0x80,0) 29

Each 8-byte half carries a tag or subtype byte in its last position, from a
small closed set. The shared 0x6d is what suggests one vocabulary used twice
rather than two unrelated fields.

This answers the question the previous commit left open. There is no per-record
length field: the best candidate offsets hold the value 16 on at most 13% of
records, which is the chance rate for small integers, not a self-describing
record. The records are therefore fixed 16 bytes, and the tiling is not a
coincidence of variable-length records that happen to be multiples of 16.

Still open: what the four and two tag values mean, and what the 14 varied bytes
encode. The tag vocabulary is small enough to enumerate against known PS2
primitive lists, which is the reference to bring in next.

docs/plan/level-assets.md

@@ -1219,6 +1219,46 @@ payload is a flat table; if they are variable, the 16-byte alignment is a
 coincidence of every record happening to be a multiple of 16 long. The stride
 scan cannot separate the two, because both produce a peak at 16.
 
+**Follow-up: the records are two 8-byte halves, each with a tag byte.**
+
+**Range measured:** level 0, the 1,636 sixteen-byte records following the
+header across all 29 packets. Per-byte distinct counts, not pooled.
+
+**Method:** count distinct values and zero frequency at each of the 16
+positions; then tabulate the joint distribution of the two low-entropy
+positions.
+
+**Result.** Fourteen of the sixteen positions are uniformly varied -- 101 to
+153 distinct values, zero in 13% to 58% of records. Two are not:
+
+| byte | distinct | values (count) |
+|---|---|---|
+| 7 | **4** | 0 (1432), 0x30 (135), 0x6d (40), 0x80 (29) |
+| 15 | **2** | 0 (1618), 0x6d (18) |
+
+Both sit in the last byte of an 8-byte half, eight bytes apart, and both take
+values from a small vocabulary rather than the full byte range. The joint
+distribution is sparse and shows no case where both are non-zero except
+`0x6d` appearing in either position but never both:
+
+    (0,0) 1414   (0,0x6d) 18   (0x30,0) 135   (0x6d,0) 40   (0x80,0) 29
+
+**Reading.** Each 8-byte half carries a tag or subtype byte in its last
+position, drawn from a small closed set. The shared value `0x6d` in both
+positions is what suggests one vocabulary used twice rather than two unrelated
+byte fields.
+
+**What this settles about variable length.** There is **no per-record length
+field**: the best candidate offsets hold the value 16 on at most 13% of
+records, which is the rate small integers appear by chance, not a self-
+describing record. So the records are fixed 16 bytes, and the unresolved
+question from the previous entry is answered -- the tiling is not a coincidence
+of records that happen to be multiples of 16 long.
+
+**Still open:** what the four and two tag values mean, and what the 14 varied
+bytes encode. The tag vocabulary is small enough to enumerate against known
+PS2 primitive lists, which is the obvious next reference to bring in.
+
 **The retracted VIF reading is not being revived.** Nothing here identifies a
 VIF stream: the 16-byte tiling is uniform across all 29 packets with no
 command-shaped tail, and a VIF packet would show a changing command byte in its