Decode the tie class header's +0x0c word: three LOD record counts

Range measured: every tie class on the disc, 1,864 classes over all 27 levels.

Method: read the word at class +0x0c as four bytes, and read the record counts
independently from the blocks themselves -- follow packets[lod] to the block,
walk to the 0xf6 terminator, and count the 16-byte records the block header's
data_offset names. Two paths to the same number, so the check is not circular.

Result: the byte at +0x0c is the LOD 0 record count, +0x0d is LOD 1's and +0x0e
is LOD 2's, on 1,864 of 1,864 classes. Classes with an absent LOD agree too:
a zero packets[lod] gives a zero count and the byte is zero.

This closes the file's oldest lie about the tie header. The comment in
TieClassHeader::parse read "0x0c: the 64 light-slot normals offset. Read past,
not decoded" -- inherited from R&C1's layout, where the word genuinely is an
offset. On R&C2 it is not an offset at all; it is three counts, and R&C1 carries
the same quadruple at +0x20. Skipping the field was the right action on the
wrong information: the field was unknown only because R&C1's map was applied to
R&C2's bytes.

TieClassHeader gains packet_counts, and
tie_class_header_counts_records_per_lod asserts the agreement.

The fourth byte, +0x0f, is left unnamed. It ranges 1..15, and the obvious
following of R&C1 -- the shader/ad-gif total -- disagrees on 1,827 of 1,864
classes, which is 2% agreement where a count would expect 100%. It is recorded
as unidentified rather than given a name that fits a fiftieth of the population.

docs/roadmap.md

@@ -275,6 +275,14 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       V4_8 parent arrays, weight running zero to one across each band); verifying
       them needs the **camera distance at the savestate** so the weight can be
       computed and compared against the rendered result.
+- [x] The tie class header's **`+0x0c` word is the three LOD record
+      counts** — LOD 0 at `+0x0c`, LOD 1 at `+0x0d`, LOD 2 at `+0x0e` — verified
+      on **1,864 of 1,864** classes by reading the counts independently from
+      the blocks' own record tables. This was filed as "R&C1's normals offset,
+      read past, not decoded", which was the right action on the wrong map:
+      R&C1 carries the same quadruple at `+0x20` and it is not an offset on
+      R&C2. The fourth byte is unidentified and is *not* the shader total
+      (disagrees on 1,827 of 1,864).
 - [x] `tie` — **fully chained.** `resolve_tie_class` walks both indirections: the
       class table is in `core_index.bin`, and the entry's `offset_in_asset_wad`
       addresses `core_data.bin` (not `core_data.wad`). All **1,864** tie classes