Locate the tfrag terrain region and record what its records look like

The core header field at 0x08 is zero on all 27 levels, and the seven offsets
0x0c, 0x10, 0x14, 0x60, 0x64 and 0x68 are strictly increasing on every level.
Reading them as a sequence of region boundaries gives the layout of core_data:

  tfrag      [0, occlusion)
  occlusion  [occlusion, sky)
  sky        [sky, collision)
  collision  [collision, textures_base)

So tfrag = 0 is a real value rather than a missing field, and the terrain is the
first 2.12 MB of level 0's geometry.

The terrain begins with a short header followed by a repeating 64-byte record
from 0x40. Established about those records: byte columns 3, 7, 11 and 15 are
0x48 in every record, which are high bytes of four s16 values giving a near-fixed
Y on a planet of radius about 2,187; columns 16 and 17 increase steadily across
records like a grid walk; and columns 48-51 carry a repeating ffff00ff pattern
characteristic of GS packet headers.

The record layout itself is not yet recovered, and the write-up says so rather
than guessing. Ruled out and recorded: uncompressed f32 vertices (the longest
plausible float run in 16.9 MB is a run of zeros in the collision block, so
vertices are packed); GS packet tags at every position (0xE0..0xEF is frequent
but uniform, which is what packed data looks like); and a 48-byte record stride
(the pattern repeats at 64).

Also confirmed this session: the core header base is offset 0 with certainty,
because the compressed and decompressed sizes of core_data appear at the same
offsets (0x88 and 0x8c) in all 27 levels' core_index. And the occlusion block at
the header's 0x0c offset reads as an ascending u16 array of 65 values before
restarting, consistent with per-cell visibility records.

No code change: this is the reverse-engineering record for the next parser. 75
unit tests, clippy clean.

docs/roadmap.md

@@ -104,9 +104,13 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 
 - [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.
+- [ ] `core_index` class tables — the header base is confirmed (the compressed
+      and decompressed sizes of `core_data` sit at the same offsets in all 27
+      levels), and every offset lands inside `core_data`. But the class-table
+      fields do not decode under any field order or stride tried. Ruled out and
+      written up in `plan/level-assets.md`. Next: identify `tfrag` by its own
+      structure instead of through the header.
+- [x] `occlusion` and `sky` offsets located and their first bytes read.
 - [ ] `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