Establish that the loader produces the RAM packet forms, not the disc

Everything previously reported about five-block sub-lists and fixed-point
payloads was read out of the running game. Checking the same packets on disc
settles what the disc actually stores.

Range measured: level 0, all 29 packets named by the +0x40 tables of the 6
bounded spans, read at their span-relative offsets; 1636 whole 16-byte records
after the 16-byte header.

Neither RAM form exists on disc:

                     disc              RAM
  00 00 00 30 per    exactly 1         exactly 5
  sub-list packet
  blocks at 0/32/64  0 of 10           11 of 11
  fixed-point byte3  0 of 19           100%
  == 0x80

The 29 packets split 10 sub-list / 19 fixed-point by whether they contain
00 00 00 30 at all, and not one of the ten has the block structure, and not one
of the nineteen has the fixed-point marker.

The disc body is a compact 16-byte record stream:

  +000: 04 04 00 01 | 00 00 00 00 | 00 00 00 05 | 00 80 0e 6c
  +010: 02 00 00 00 | 05 00 00 00 | 32 00 00 00 | 0e 00 00 00
  +020: 09 00 00 00 | 00 40 3e 30 | 12 04 00 00 | 05 00 00 00
  +030: 09 00 00 00 | 00 40 3e 30 | 12 04 00 00 | 21 00 00 00

Small u32 fields and a repeating 00 40 3e 30 12 04 00 00. Per position over all
1636 records the same two outliers hold: byte 7 takes 4 distinct values and byte
15 takes 2, against 101 to 153 everywhere else.

Byte 7 is per-record, not per-packet: the first record of all 29 packets has
byte 7 = 0x00. The four-value vocabulary varies within a packet body rather than
tagging the packet, which is why grouping packets by it never separated the two
kinds.

Consequence for Phase 2: the payload is encoded on disc and expanded at load, so
a disc parser can bound it and check its signature but cannot read it as either
RAM form. Decoding it means reversing the expansion, not re-describing what the
loader produced. That is the honest boundary of what is known.

docs/plan/pcsx2-verification.md

@@ -626,3 +626,48 @@ which is consistent with vertex positions relative to a per-payload origin.
 decodes to vertices -- the payload entropy is far below random, so it is
 compressed or permuted rather than stored plainly, and the permutation table
 seen once in `0x009376f0` remains unexplained.
+
+## The loader produces the RAM forms: the disc payload is neither of them
+
+Everything above about five-block sub-lists and fixed-point payloads was read
+out of the running game. Checking the same packets on disc settles what the
+disc actually stores.
+
+**Range measured:** level 0, all 29 packets named by the `+0x40` tables of the 6
+bounded spans, read at their span-relative offsets; 1,636 whole 16-byte records
+after the 16-byte header.
+
+**Result: neither RAM form exists on disc.**
+
+| | disc | RAM |
+|---|---|---|
+| `00 00 00 30` per sub-list packet | **exactly 1** | exactly 5 |
+| sub-list blocks at 0, 32, 64 | **0 of 10** | 11 of 11 |
+| fixed-point byte 3 == `0x80` | **0 of 19** | 100% |
+
+The 29 packets split 10 sub-list / 19 fixed-point by whether they contain
+`00 00 00 30` at all, and not one of the ten has the block structure, and not
+one of the nineteen has the fixed-point marker.
+
+**What the disc body actually is.** A compact 16-byte record stream:
+
+    +000: 04 04 00 01 | 00 00 00 00 | 00 00 00 05 | 00 80 0e 6c
+    +010: 02 00 00 00 | 05 00 00 00 | 32 00 00 00 | 0e 00 00 00
+    +020: 09 00 00 00 | 00 40 3e 30 | 12 04 00 00 | 05 00 00 00
+    +030: 09 00 00 00 | 00 40 3e 30 | 12 04 00 00 | 21 00 00 00
+
+Small `u32` fields and a repeating `00 40 3e 30 12 04 00 00`. Per position over
+all 1,636 records the same two outliers hold as on the earlier disc pass: byte 7
+takes 4 distinct values and byte 15 takes 2, against 101 to 153 for every other
+position.
+
+**And byte 7 is per-record, not per-packet.** The first record of all 29
+packets has byte 7 = `0x00`. So the four-value vocabulary is a field that varies
+within a packet body, not a tag on the packet -- which is why grouping packets
+by it never separated the two kinds.
+
+**Consequence for Phase 2.** The packet payload is encoded on disc and expanded
+at load, so the disc parser can bound it and check its signature but cannot read
+it as either RAM form. Decoding it means reversing the expansion, not
+re-describing what the loader produced. That is a larger job than the framing
+work so far, and it is the honest boundary of what is currently known.