Follow shrub packet pointers: adjacent records hold unrelated payloads

The header pointers found in the previous commit are live, so they can be
dereferenced. Two records 0x30 apart in the level 0 table at 0x22a6b8 were
followed.

Range measured: savestate slot 1, reading 0x00936a70 (from the record at
0x22a6b8) and 0x009376f0 (from the record at 0x22a6e8), 64 bytes each.

The two payloads have nothing in common.

0x00936a70 is fixed-point vertex data:

  8d 8c 80 80  89 87 7c 80  8d 8c 80 80  89 87 7c 80
  4e 4e 4c 80  4e 4e 4c 80  4e 4e 4c 80  4e 4e 4c 80   repeating

Every high byte is 0x80 or 0x7c and the pattern repeats on an 8-byte boundary.
As s16 these are large negatives in a narrow band around -32500, consistent
with Q16.15 fixed point rather than f32, and with a stride of 4 s16 per vertex.

0x009376f0 is a tagged sub-list, not vertex data:

  00 00 00 30  cd 00 00 00  cd 00 00 00  cd 00 00 00
  cd 00 00 00  01 00 00 05  22 c1 01 6e  00 00 00 00

Structurally different: small integers, a repeating 0xcd, 0x30 tags in the high
byte. Nothing here is position data.

This supports the type reading of the header: the table is a tagged collection
where the tag selects the payload kind, not a uniform array. It also rules out
the alternative that the 16-byte tiling was one uniform record format with
varying fields -- two adjacent records with unrelated payloads is not that.

Still open: the mapping from tag value to payload kind. The 0x30 appearing in
record bytes 8-11 in RAM also heads the second payload, which is suggestive
but is one coincidence so far and is deliberately not written up as a link.

docs/plan/pcsx2-verification.md

@@ -211,3 +211,45 @@ as data by something, not stored as a tag.
 `0x6d` marks a payload that the loader expands. That needs the same records
 compared one by one against their disc spans, which is the next step and is
 now cheap because the anchor exists.
+
+## Following the pointers: packet payloads differ by type
+
+The header pointers found above are live, so they can be dereferenced. Two
+consecutive records from the level 0 table at `0x22a6b8` were followed.
+
+**Range measured:** savestate slot 1, reading `0x00936a70` (from the record at
+`0x22a6b8`) and `0x009376f0` (from the record at `0x22a6e8`), 64 bytes each.
+
+**Result: the two payloads have nothing in common.**
+
+`0x00936a70` -- fixed-point vertex data:
+
+    8d 8c 80 80  89 87 7c 80  8d 8c 80 80  89 87 7c 80
+    4e 4e 4c 80  4e 4e 4c 80  4e 4e 4c 80  4e 4e 4c 80   (repeating)
+
+Every high byte is `0x80` or `0x7c`, and the pattern repeats on a 8-byte
+boundary. Read as `s16` these are large negatives in a narrow band around
+-32500. That is consistent with Q16.15 fixed-point rather than `f32`, and with
+a stride of 4 `s16` per vertex.
+
+`0x009376f0` -- a tagged sub-list, not vertex data:
+
+    00 00 00 30  cd 00 00 00  cd 00 00 00  cd 00 00 00
+    cd 00 00 00  01 00 00 05  22 c1 01 6e  00 00 00 00
+
+Structurally different: small integers, a repeating `0xcd`, and `0x30` tags in
+the high byte. Nothing here is position data.
+
+**What this supports.** Two records 0x30 apart in the same table hold payloads
+of entirely different kinds. That is direct evidence for the type reading of
+the header: the table is a tagged collection where the tag selects what the
+payload is, not a uniform array of one thing.
+
+It also rules out the alternative I could not previously exclude -- that the
+16-byte tiling was a single uniform record format and the varying bytes were
+all fields of it. Two adjacent records with unrelated payloads is not that.
+
+**Still open.** The mapping from tag value to payload kind. The `0x30` that
+appears in record bytes 8-11 in RAM also appears at the head of the second
+payload, which is suggestive but is one coincidence so far and should not be
+written up as a link until it is seen in more than one record.