Fix level extents read as bytes, and extract the level geometry

A defect in the Phase 1 extractor, found by reading the data extent's contents:
level extents are declared in sector counts, the generic G/ pair table uses byte
counts, and level containers were being routed through the generic path. So
LEVEL0.WAD's data extent -- 6,484 sectors -- was taken as 6,484 bytes. Every
test still passed, because a truncated file is still a file.

The extent's own header gave it away: it declares an uncompressed total of
13,277,920 bytes, and 13,277,920 / 6,484 is 2047.7. A ratio landing on 2048 is
a unit error, not a compression ratio. Across 27 levels this had been discarding
roughly 300 MB of level content.

Level containers now go through the typed LevelHeader instead. Level 0 yields:

  data.bin         13,279,232   the data extent
  core_data.wad     9,738,678   the geometry, compressed
  core_data.bin    16,969,296   the geometry, decompressed
  core_index.bin       31,600   the geometry directory
  gameplay.bin       659,456
  sound_bank.bin   1,503,232

core_data is a WAD LZ77 stream -- the format already implemented for the game --
and it decompresses cleanly. The first real level content this project has
recovered.

New: LevelDataHeader parses the data extent's own header, a table of byte ranges
naming the level overlay executable, the geometry directory, the GS RAM image,
the HUD banks and the geometry. Note this is a third meaning for a "size" field
on the same disc, after sector counts in the level header and byte counts in the
generic table; all three are documented together in level-data.md so the next
parser does not rediscover this the hard way.

The geometry directory's offsets were checked against the geometry rather than
taken on trust: all twelve land inside the 16.9 MB of decompressed core_data,
which is what confirms the header is being read correctly. The class tables
themselves do not yet decode under the documented layout, and that is recorded
as open work in plan/level-assets.md rather than papered over.

75 unit tests, 9 integration tests against the real disc. Hash table regenerated
at 5,159 files and 5,671,915,799 bytes -- hashes only, no content. Extraction
now writes to ~/Documents/gc-extracted rather than /tmp, which is 16 GB and did
not have room for a 5.3 GB output.

docs/roadmap.md

@@ -16,10 +16,11 @@ early, while they are still cheap to retire.
 - [x] **Phase 1 complete.** The disc pipeline runs end to end and is verified
       against a committed hash table: 5,135 files, 4,500,106,960 bytes, every
       one of the 92 asset containers parsing.
-- [x] **Phase 2 started.** The level container header is parsed and typed, which
-      names the `data`, `sound_bank`, `gameplay` and `occlusion` extents inside
-      each of the 27 level containers.
-- [ ] Phase 2 next: the `gameplay` extent, then `data`.
+- [x] **Phase 2 in progress.** Level containers are parsed through their typed
+      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: the geometry directory's class tables, then `tfrag` terrain.
 
 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,
@@ -101,6 +102,11 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 
 **In progress:**
 
+- [x] `data` — the extent header locates `core_index` and `core_data`; the
+      geometry decompresses and is verified on level 0.
+- [ ] `core_index` class tables — offsets all land inside `core_data`, which
+      confirms the header, but the `ArrayRange` fields do not decode to a usable
+      class table under the documented layout. Next thing to resolve.
 - [ ] `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