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/formats/core-data-regions.md

@@ -2570,6 +2570,50 @@ correct stride, which is not yet known. The LOD1/LOD2-sharing test
 (96.1% same class against 0.4% different) remains the strongest evidence that
 the first slots are positional, and it is insensitive to stride.
 
+## The tfrag morph is not a rewrite of the position arrays (2026-10-14)
+
+**Range measured:** level 0, all 833 tfrag patches, live PINE RAM against the
+disc.
+
+The morph was recorded as unverifiable because "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". That reading is right about the
+correspondence and wrong about the cause, and the cause is now measurable.
+
+**The game rewrites bytes inside the tfrag blocks, and none of them are in a
+position.**
+
+    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
+
+The position ranges total 490,224 bytes and not one of them differs. The two
+measurements agree independently: walking the VIF lists and comparing parsed
+positions gives 40,600 identical and zero changed, and a raw per-byte diff of
+each patch's own extent classifies every differing byte.
+
+So the blend is not precomputed into the geometry. It happens at draw time, in
+the VU stream -- which is the standard PS2 arrangement and is why no weight was
+ever readable from RAM: there was nothing there to read. The rewrites are
+mostly packet framing (70% command words) plus some other unpack payloads
+(30%), which is consistent with the loader rebuilding the VIF packet for the
+tier it selected while leaving the vertex data alone.
+
+**Extents.** Each patch's extent is the gap to the next patch's `data` pointer,
+which is exact and needs no guess about which header field marks a patch's end.
+The block is located in RAM by the first table record matched under the
+invariant mask, the same way `gc-trace` locates it.
+
+Asserted by `tfrag_positions_are_verbatim_and_the_rewrites_are_elsewhere`,
+gated on `GC_SSTATE`. The test also requires the rewrites to be non-trivial
+(more than 100,000 bytes) and to be mostly command words, so a RAM image that
+happened to be a verbatim copy of the disc -- which would make the zero look
+good for the wrong reason -- fails instead.
+
 ## Most of the chunk container is level-independent
 
 Comparing every chunk record against the same record index in the other 26
@@ -3483,7 +3527,7 @@ the time.
 the shuffle margin, so a claim that the period is not 64 fails rather than
 sailing through.
 
-## Attempting the moby_anim unblock: the class header, and where it stalls## Attempting the moby_anim unblock: the class header, and where it stalls
+## Attempting the moby_anim unblock: the class header, and where it stalls
 
 `MobyInstance` names `animSeq`, `animLayers`, `jointCnt` and `jointCache` as
 runtime pointers. Those pointers are useless on the disc -- they are RAM