Resolve both tie indirections on all 1,864 classes, and disprove a sample artifact

resolve_tie_class walks the chain, which is two steps and both are easy to get
wrong:

  1. The tie class table lives in core_index.bin, not core_data.bin. On level 0
     the tables chain as moby at 192, 238 x 32 bytes later tie at 7808, 74 x 32
     later shrub at 10176, which closes. Reading the same table out of
     core_data.bin produces plausible garbage rather than an error.
  2. ClassEntry::offset_in_asset_wad addresses core_data.bin, despite the field
     name and despite core_data.wad sitting alongside it.

Verified: all 1864 tie classes resolve, o_class agreeing on every one, and all
5592 LOD block offsets land inside core_data.

Disproved, and this is the part worth reading: the word at +0 of a 16-byte unit
inside an LOD block. On the first twelve units of level 0's class 0 it rises
strictly -- 288, 1520, 2848, 3968, 5088, 6096, 7312, 8528, 9792, 10976, 12016,
13072 -- which reads exactly like a linked list, and the accompanying i16s looked
quantised, two distinct values in i16[0] and three in i16[1].

Across the population it is strictly increasing on 0 of 1864 blocks, and i16[0]
takes 8969 distinct values on level 0 alone rather than two. The sample was
twelve units out of 1,724,334. Both the monotonic reading and the quantisation
were artifacts of that sample.

That is the pooled-claim error AGENTS.md rule 3a exists to prevent, committed
almost verbatim: the first twelve units looked clean, and I was one step from
writing "u32[0] is a linked list of runs" into a format spec. The test now
asserts the disproof, so it cannot creep back.

Not established: the block's record size. 3580 non-empty LOD blocks compute as
divisible by 16, but some packets offsets run backwards, so the "next offset
delimits this block" end is wrong for them and that figure should not be trusted.
The tie layout stays partial: indirections and header done, records not.

docs/formats/core-data-regions.md

@@ -1097,3 +1097,34 @@ six bytes remain uninterpreted.
 hand-computed `o_class` offset instead of `ShrubClassEntry`, and every
 `ShrubHeader::region` call failed. The parser was not wrong; the caller was.
 The working call shape was already in the disc test.
+
+## tie: both indirections, and one reading disproved
+
+**The chain, which is two steps and easy to get wrong.** The tie class **table**
+lives in the level's `core_index.bin`, not `core_data.bin`. On level 0 the three
+tables chain as moby at `192`, 238 x 32 bytes later tie at `7808`, 74 x 32 later
+shrub at `10176`, which closes. Reading the same table out of `core_data.bin`
+produces plausible garbage rather than an error -- `offset_in_asset_wad` comes
+back as 1,217,208,842, which is outside every buffer, so the mistake announces
+itself if you look. Then `ClassEntry::offset_in_asset_wad` addresses
+**`core_data.bin`**, despite its name and despite `core_data.wad` sitting
+alongside it.
+
+**Verified:** all **1,864** tie classes resolve, `o_class` agreeing on every one,
+and all **5,592** LOD block offsets land inside `core_data`.
+
+**Disproved:** the word at `+0` of a 16-byte unit inside an LOD block. On the
+first twelve units of level 0's class 0 it rises strictly -- 288, 1520, 2848,
+3968, 5088, 6096, 7312, 8528, 9792, 10976, 12016, 13072 -- which reads exactly
+like a linked list, and the accompanying `i16`s looked quantised (two distinct
+values in `i16[0]`, three in `i16[1]`).
+
+Across the whole population it is strictly increasing on **0 of 1,864** blocks,
+and `i16[0]` takes **8,969** distinct values on level 0 alone rather than two.
+The sample was twelve units out of 1,724,334. Both the monotonic reading and the
+quantisation were artifacts of that sample, and the disproof is asserted in
+`crates/gc-extract/tests/disc.rs` so it cannot creep back.
+
+**Not established:** the block's record size. 3,580 non-empty LOD blocks compute
+as divisible by 16, but some `packets` offsets run backwards, so the "next offset
+delimits this block" end is wrong for them and the figure should not be trusted.

docs/roadmap.md

@@ -241,11 +241,21 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 - [~] `tfrag` — vertex format, topology, texture bindings, per-vertex colour
       and normals, LOD selection and parent indices are all recovered and
       verified. **Still open:** morph targets and the strip/chain bookkeeping.
-- [ ] `tie` — class table and the 0x48-byte header agree with R&C1; the
-      **vertex layout is not decoded**. The class table entries are pointers
-      into `core_data.wad`, and the header's `packets[0..3]` LOD offsets are
-      resolved against the lump base -- neither chain has been walked end to
-      end yet. Level 0 has 74 tie classes, 238 moby and 7 shrub.
+- [~] `tie` — **both indirections now resolve.** `resolve_tie_class` walks the
+      chain: the class table is in `core_index.bin`, and the entry's
+      `offset_in_asset_wad` addresses `core_data.bin` (not `core_data.wad`,
+      despite the field name). All **1,864** tie classes resolve, with
+      `o_class` agreeing on every one, and all **5,592** LOD block offsets land
+      inside `core_data`.
+- [ ] The tie **block layout is not decoded.** LOD0 blocks are not a uniform
+      stride of records: 3,580 non-empty blocks compute as divisible by 16,
+      but that figure is not trustworthy because some `packets` offsets run
+      backwards, so the "next offset" end is wrong for them. One reading is
+      **disproved**: the word at `+0` of a 16-byte unit is strictly increasing
+      on **0 of 1,864** blocks, despite looking exactly like a linked list on
+      the first twelve units of one class. A 12-unit sample of a 1.7M-unit
+      population is the pooled-claim error rule 3a exists to prevent; the test
+      now asserts the disproof so it cannot creep back.
 - [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at
       32 still gives 231 sane-looking entries of 358, which is the hazard).
       Geometry header parsed and checked field by field on all 358 spans: