Bring the roadmap's chunk section up to date

Four commits of chunk work -- uniform record length, the leading-byte phase
counter, the two-byte record index, and the PCSX2 RAM findings -- were written to
docs/formats/core-data-regions.md and docs/plan/pcsx2-verification.md but never
reached the roadmap, because the scripted replacements kept missing their target
text and I did not check that they had applied.

That is the staleness complained about earlier recurring through a different
route: not a missing edit, but a silently-failed one. The tie, collision and
level_overlay entries had landed; only the chunk ones had not.

Rewritten from the commits rather than from memory, and the numbers are the ones
the tests assert: 1,509 chunks, 34,491 records, uniform length 1,509/1,509,
phase counter 1,262/1,509, index rule 1,235/1,509, RAM prefix 02 00 on 90/90.

docs/roadmap.md

@@ -338,11 +338,31 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 - [x] **The post-shrub chunk container.** A 16-byte header, a 10-byte zero gap,
       then offsets tagged `0xF0000000 | low24` resolving to `chunk_start + low`;
       header byte 14 is the record count, equal to `offsets.len()` on 1,123 of
-      1,123 chunks across all 27 levels. **77 distinct chunk types, 1,123
+      1,123 chunks across all 27 levels. **77 distinct chunk types, 1,509
-      chunks, 19,546 records, 50 strides.** Moby class IDs enrich at 9,493 hits
+      chunks, 34,491 records.** Moby class IDs enrich at 9,493 hits against
-      against 246.1 expected with contiguous per-type arrays -- but the arrays
+      246.1 expected with contiguous per-type arrays -- but the arrays land in a
-      land in a different place for each type, so no single pooled scan finds
+      different place for each type, so no single pooled scan finds them.
-      them. The record *fields* are not decoded.
+- [x] **Chunk record framing is closed.** Every chunk has a **uniform record
+      length** (1,509 of 1,509) -- length varies *between* chunks of a type, never
+      within one, which withdrew an earlier "variable-length type" claim that had
+      been pooled across chunks. The record's leading byte is a **per-chunk phase
+      counter** (`bucket_rule`, 1,262 of 1,509 chunks) and on **1,235** of them
+      *both* leading bytes encode the record's own index in mixed radix
+      (`index_rule`), so the leading bytes carry no per-record information.
+- [x] **The loader's transformation, from PCSX2 RAM.** Disc offsets
+      `0xf0000000 | low24` are rewritten in RAM to absolute EE pointers
+      `0xf1850000 | low24` -- tag replaced by the chunk's load base, low 24 bits
+      untouched -- and every record gains a constant `02 00` prefix that the
+      rewritten table points at *instead of* the record data (**90 of 90**
+      records). The payload itself is copied **verbatim**. The index finding is
+      corroborated live: the byte at `+2` takes exactly `0, 16, ... 240`, the 16
+      values `index_rule` predicts.
+- [ ] The chunk **record fields are not decoded**, and no type is named. The body
+      is dense (74% of `f32` reads plausible against a 49% random control) with
+      an index-like tail -- 12 of 163 `u16` slots in the largest type stay below
+      `0x1000` -- but **no count field** exists in the first 64 body bytes at any
+      width or stride tried. Only **9.4%** of `u16` slots are per-chunk constant,
+      so records are not templates.
 - [x] **Moby class arrays are contiguous per type, and the pooled scan was
       wrong.** See rule 3a in `AGENTS.md`: the original claim of a `u16` array at
       slots 129-140 was the largest-stride type dominating an aggregate. Per