Resolve tfrag LOD parent linkage: guard absent tiers by their counts

The four V4_8 parent arrays are classified by VU address, but the
addresses collide: on level 0 patch 1,
unk_indices_2_lod_01_addr == parent_indices_lod_0_addr == 291, and
unk_indices_2_lod_0_addr == indices_addr == 294. Matching on address
alone cannot separate them, and it fails silently -- the arrays still
parse, they just hold the wrong numbers.

Two corrections, and the first one is worth recording because it looked
like a data problem rather than a code one:

Each V4_8 element is 4 bytes and holds four indices, so an array of N
entries is count*4 bytes, not count. An earlier analysis compared the
unpack's element count against the position counts and concluded that
15,000 patches could not hold enough parents. That was the wrong unit;
the data was fine.

unk_06 and unk_0a suppress an empty tier. When the extra vertex-info
count is zero there is no extra array and its address is simply the next
tier's, so guarding those branches on the count lets the address fall
through to the array that exists. That one change took resolved LOD-0
entries from 28,739 to 341,306.

Result: of 886,841 vertex-info entries across all 27 levels, 516,492 are
common and have no link by design, and all 370,349 LOD entries resolve --
29,043 LOD-01 and 341,306 LOD-0 -- with zero failures. Each resolves to a
real first parent, a LOD-01 parent that is always a common entry, and
three positions inside the patch. A common entry never claims a parent.

Morphing can now be completed: a patch knows which LOD to draw, how far
to blend each vertex toward its parents, and where those parents are.

docs/plan/level-assets.md

@@ -451,38 +451,50 @@ A morph weight runs 0 to 1 across its tier's band: LOD-01 between D1 and D0,
 LOD-0 between D2 and D1. Past the far edge of the band an entry is not morphed
 but *replaced* by its first parent — a collapse, not a blend.
 
-### What is still unresolved: the parent-index arrays
+### Parent indices: settled, but only after two corrections
 
-The four V4_8 parent arrays (`parent_indices_lod01`, `unk_indices_2_lod01`,
-`parent_indices_lod0`, `unk_indices_2_lod0`) are classified by VU address, but
-**the addresses are not unique**. On level 0 patch 1,
-`unk_indices_2_lod_01_addr == parent_indices_lod_0_addr == 291`, and the VU
-header's `unk_06` and `unk_0a` are both zero — there are no extra entries at
-all, so nothing but the order the unpacks appear in distinguishes the two.
+The four V4_8 arrays (`parent_indices_lod01`, `unk_indices_2_lod01`,
+`parent_indices_lod0`, `unk_indices_2_lod0`) are classified by VU address,
+and **the addresses are not unique**. On level 0 patch 1,
+`unk_indices_2_lod_01_addr == parent_indices_lod_0_addr == 291`, and
+`unk_indices_2_lod_0_addr == indices_addr == 294`. So address matching alone
+cannot separate them, and getting it wrong is silent: the arrays still parse,
+they just hold the wrong numbers.
 
-The consequence is measurable. Across all 27 levels, of 886,841 vertex-info
-entries, 516,492 are common and 57,782 LOD entries resolve to a parent. But
-316,548 LOD-0 entries have no recorded parent against only 28,739 that do, and
-only 3,274 of 18,102 patches carry enough V4_8 bytes to cover
-`positions_lod_01_count + positions_lod_0_count + extras`. The asymmetry is too
-large to be genuine, so one of two things is true: the parent arrays are being
-misassigned where addresses collide, or RAC2's VU header means something
-different by `positions_lod_0_count` than RAC1's does.
+Two things were needed to fix it, and the first attempt at getting it wrong is
+worth recording because it looked like a data problem rather than a code one.
 
-The vertex-info tiers themselves *are* confirmed — the addresses at +9 and +11
-do match the observed V4_16 unpacks, and the three tier counts sum to
-`vert_count` on every patch. So the header layout is right; it is specifically
-the parent arrays that are unresolved.
+**Each V4_8 element is 4 bytes and holds four indices**, so an array of N
+entries is `count * 4` bytes, not `count`. An early analysis compared the
+unpack's element count against the position counts and concluded that 15,000
+patches could not possibly hold enough parents. That was the wrong unit; the
+data was fine.
 
-Ruled out for now: address-only classification (collides), and assuming the
-arrays are one entry per position (fails on 15,000 patches). Not yet tried:
-ordering by VU address rather than by declaration, and using `unk_06`/`unk_0a`
-to suppress an empty tier before falling through to the next candidate.
+**`unk_06` and `unk_0a` suppress an empty tier.** When the extra vertex-info
+count is zero there is no extra array, and its VU address is simply the next
+tier's. Guarding those two branches on `unk_06 != 0` / `unk_0a != 0` lets the
+address fall through to the array that actually exists. This one change took
+resolved LOD-0 entries from 28,739 to 341,306.
+
+### Verification
+
+Every vertex-info entry across all 27 levels is now accounted for: of 886,841
+entries, 516,492 are common and have no link by design, and **all 370,349 LOD
+entries resolve** — 29,043 LOD-01 and 341,306 LOD-0 — with zero failures. Each
+resolves to a first parent that is real vertex info, a LOD-01 parent that is
+always a common entry, and three positions inside the patch. A common entry
+never claims a parent.
+
+Ruled out along the way: address-only classification (addresses collide), and
+one parent array entry per unpack element (wrong unit).
 
 ### Still open
 
-The parent arrays above, and the GS register values the level load builds from
-the texture entry (TBP0/TBP1 and so on) for a renderer that emulates the GS
-rather than resolving addresses itself. A tfrag can be turned into positioned,
-UV-mapped, textured triangles and told which LOD to draw; morphing cannot be
-completed until the parent arrays resolve.
+The GS register values the level load builds from the texture entry (TBP0/TBP1
+and so on), which a renderer needs if it emulates the GS rather than resolving
+texture addresses itself, and the guard-band clip test that sends patches
+crossing the guard band to the clipping program.
+
+A tfrag can now be turned into positioned, UV-mapped, textured triangles,
+told which LOD to draw, and morphed toward its parents at the right rate.
+Everything needed for a first frame is parsed and verified.

docs/roadmap.md

@@ -20,7 +20,8 @@ early, while they are still cheap to retire.
       header, and the `data` extent is parsed as a container of byte ranges. The
       geometry decompresses: level 0 yields 16,969,296 bytes of level content
       from a 9.7 MB stream.
-- [ ] Next: tfrag parent indices, then the first drawable frame.
+- [ ] Next: the first drawable frame — build the GS register set and a
+      Bevy fly-camera over level 0's tfrags.
 
 The disc being the exact build the reference projects pin is the single
 biggest favourable fact so far: no disc conversion, no regional timing work,
@@ -147,11 +148,12 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       the coarser mode and distance never moves back to finer detail. Morph
       weights run 0..1 across each tier's band, and collapse replaces an entry
       with its first parent rather than blending it.
-- [ ] tfrag parent indices: the four V4_8 arrays are classified by VU address,
-      but the addresses collide (`unk_06` and `unk_0a` are zero, so an absent
-      tier shares the next one's address). 57,782 of 374,349 LOD entries
-      resolve; the 316,548 unresolved LOD-0 entries are far too lopsided to be
-      genuine. Tried and ruled out in `plan/level-assets.md`.
+- [x] **tfrag parent indices.** The four V4_8 arrays are classified by VU
+      address, but the addresses collide, and each V4_8 element holds four
+      indices so an array is `count * 4` bytes rather than `count`. With
+      `unk_06`/`unk_0a` suppressing absent tiers, all 370,349 LOD entries
+      across the 27 levels resolve: 29,043 LOD-01 and 341,306 LOD-0, zero
+      failures. See `plan/level-assets.md` for the two corrections.
 - [ ] `gameplay` — begins `WAD` + a per-level byte, and does *not* decode with
       the WAD LZ77 decoder. All 27 levels fail identically, so the input is
       wrong rather than the decoder. Ruled out: bit order, header length, the