Verify the tfrag record framing against RAM: two pointer fields, morphed vertices

The tfrags block header -- table_offset 0x40, tfrag_count 833, lod_distance 32.0
-- hits once in the level-0 savestate at RAM 0x848000, so disc offset 0 maps to
RAM 0x848000 and the block can be compared position for position.

Result 1: exactly two fields per record are rewritten. Comparing all 833 64-byte
table records field by field:

  records compared        833
  u32 fields differing    1,665 = 833 x 2, and no others
  their offsets           +0x10 and +0x38, on every record
  relocation delta        8,683,584 = 0x848000, on 833 of them

So +0x10 and +0x38 are block-relative pointers and the loader adds the block's
RAM base to each. Every other byte of all 833 records is verbatim. Six fields
differ by 0xF80000 and 0x1F00000 instead -- three records pointing into a
different buffer, recorded rather than averaged.

This names two fields the disc-side work had left as `data` and an unnamed word.

Result 2: behind the pointers, about 8.6% of bytes are rewritten. Following
record 0's +0x10 to disc 0xd040 / RAM 0x855040 and comparing 16 KiB: 14,977 bytes
identical, 1,407 differ = 8.6%. The differences spread across many field positions
rather than concentrating, which is what morphed POSITIONS look like -- topology,
UVs, counts and command lists stay verbatim while a fraction of the position bytes
move. 8.6% is about half of a 16-byte vertex's six position bytes, consistent with
roughly half the vertices in this patch mid-morph at the saved camera distance.

Not established: that the morphed bytes match resolve_vertex's formula. That needs
mapping RAM vertices to disc vertex indices and solving for the weight, which is
the next step -- but the framing is now known well enough to attempt it, and the
two pointer fields are confirmed rather than inferred.

This also answers the "is morphing real?" question that made the earlier tfrags
probe fail to match RAM: the tfrags block is not verbatim in RAM, because both its
table pointers are relocated and its vertex positions are morphed.

docs/plan/pcsx2-verification.md

@@ -823,3 +823,42 @@ Two lessons, both already written down and both re-learned:
 - the control for this one is trivial and was not run: read the predicted RAM
   address and compare it to the disc, which takes one command and would have
   shown the verbatim copy immediately.
+
+## tfrag: two relocated pointer fields per table record, and morphed vertices behind them
+
+Checking the tfrag record framing against RAM. The tfrags block header is
+`table_offset 0x40, tfrag_count 833, lod_distance 32.0`, and that 8-byte prefix
+hits once in the level-0 savestate: **RAM `0x848000`**. So the block is at a
+known place, and disc offset 0 maps to RAM `0x848000`.
+
+**Result 1 -- exactly two fields per record are rewritten.** Comparing all 833
+64-byte table records, field by field:
+
+    records compared                833
+    u32 fields differing            1,665  = 833 x 2, and no others
+    their offsets                   +0x10 and +0x38, on every record
+    relocation delta                8,683,584 = 0x848000, on 833 of them
+
+So `+0x10` and `+0x38` are **block-relative pointers**, and the loader adds the
+block's RAM base to each. Every other byte of all 833 records is verbatim. The
+remaining six fields differ by 0xF80000 and 0x1F00000 rather than 0x848000 --
+three records pointing into a different buffer, recorded rather than averaged.
+
+This names two fields the disc-side work had left as `data` and an unnamed word.
+
+**Result 2 -- behind the pointers, about 8.6% of bytes are rewritten.** Following
+record 0's `+0x10` to disc `0xd040` / RAM `0x855040` and comparing 16 KiB:
+
+    identical bytes                  14,977 of 16,384
+    differing                         1,407  = 8.6%
+
+The differences are spread across many field positions rather than concentrated,
+which is what morphed **positions** look like: the topology, UVs, counts and
+command lists stay verbatim while a fraction of the position bytes move. 8.6% is
+about half of a 16-byte vertex's 6 position bytes, i.e. consistent with roughly
+half the vertices in this patch being mid-morph at the saved camera distance.
+
+**Not established:** that the morphed bytes match `resolve_vertex`'s formula. That
+needs mapping RAM vertices to disc vertex indices and solving for the weight, which
+is the next step -- but the framing is now known well enough to attempt it, and
+the two pointer fields are confirmed rather than inferred.