The tfrag morph is not in the data block: positions are verbatim in RAM

The morph was recorded as unverifiable because "reading a weight back out of
RAM does not work -- the positions live inside regenerated VU packets". That
is right about the correspondence and wrong about the cause. The cause is
measurable, and it comes back clean:

    patches                         833
    positions                     40,600   disc == ram
    positions identical           40,600
    block bytes differing         166,465
      inside a position unpack             0
      inside another unpack           49,484
      in a VIF command word          116,981

Range: level 0, all 833 tfrag patches, live PINE RAM against the disc. Two
independent measurements agree. Walking the VIF lists on both copies and
comparing parsed positions gives 40,600 identical and zero changed; a raw
per-byte diff of each patch's own extent classifies every differing byte, and
none of them is in a position unpack. The position ranges total 490,224 bytes.

So the blend is not precomputed into the geometry. The rewrites are packet
framing -- 70% command words -- plus other unpack payloads, which is the loader
rebuilding the VIF packet for the tier it selected while leaving the vertices
alone. The morph happens at draw time in the VU stream.

The standing note becomes a sharper one: there was never a correspondence
problem. The values were identical, so there was nothing to read.

gc-trace gains verify-morph, which does both measurements. TfragGeometry
gains position_ranges and other_ranges so the walk needed to classify a diff
is already paid for, and the ranges come from the same walk the rest of the
parse uses rather than a second one that could drift.

Per-patch extents are the gap to the next patch's data pointer. That is exact
and needs no guess about which header field marks a patch's end; the first
attempt at this compared each patch against the whole rest of the region and
reported 65 million differing bytes, which is what an unbounded comparison
looks like.

tfrag_positions_are_verbatim_and_the_rewrites_are_elsewhere is gated on
GC_SSTATE and asserts the four bounds, plus two guards: the rewrites must be
non-trivial (over 100,000 bytes) and mostly command words, so a RAM image that
was a verbatim copy of the disc -- which would make the zero look good for the
wrong reason -- fails instead.

Suite with the disc and GC_SSTATE: 68 disc tests, 156 gc-formats, 22
gc-trace, 23 gc-engine, 19 gc-game. Clippy clean.

docs/roadmap.md

@@ -267,14 +267,24 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       short structured runs with no common `u32` addend. The loader regenerates
       each patch's **VU packet stream for the LOD tier it selected**, which
       happens to every patch regardless of morphing.
+- [x] **The tfrag morph is not a rewrite of the position arrays.** Across all
+      **833** patches of level 0, live PINE RAM against the disc: **40,600**
+      positions, **40,600 identical, zero changed**. The game does rewrite the
+      blocks -- **166,465** bytes differ -- and **none** of them fall inside a
+      position unpack: 116,981 land in VIF command words and 49,484 in other
+      unpack payloads. The blend is therefore not precomputed into the geometry;
+      it happens at draw time in the VU stream, which is why reading a weight back
+      out of RAM never worked -- there was nothing there to read. This sharpens
+      the earlier "positions live inside regenerated VU packets, so there is no
+      stable per-vertex correspondence": the correspondence was never missing, the
+      values are just identical. `gc-trace verify-morph` and the
+      `GC_SSTATE`-gated test both carry the numbers.
 - [ ] What tfrag is **not** yet verified is that the morph matches
-      `resolve_vertex`'s formula. Reading a weight back out of RAM does **not**
-      work -- the positions live inside regenerated VU packets, so there is no
-      stable per-vertex correspondence. The LOD switch distances, morph weight and
-      collapse edge remain derived from the data (tiers classified from the four
-      V4_8 parent arrays, weight running zero to one across each band); verifying
-      them needs the **camera distance at the savestate** so the weight can be
-      computed and compared against the rendered result.
+      `resolve_vertex`'s formula. The blend target is still untested against the
+      game itself, and now the search space is bounded: it is in the VU stream,
+      not in the tfrag data block. Verifying it needs the **camera distance at the
+      savestate** so the weight can be computed, or a read of the VU packet stream
+      the game actually submits.
 - [x] The tie class header's **`+0x0c` word is the three LOD record
       counts** — LOD 0 at `+0x0c`, LOD 1 at `+0x0d`, LOD 2 at `+0x0e` — verified
       on **1,864 of 1,864** classes by reading the counts independently from