Decode the tie class header prefix that RAC1 and RAC2 agree on

Tie is the easy one of the three geometry subsystems -- instanced
static props, no skeleton -- so it is the right place to start.

RAC1's class header is 0x80 bytes. RAC2 agrees with it over the first
0x48 and diverges after. From 0x48 the RAC1 layout does not describe
RAC2 data: lod_info at 0x50 reads back as noise, packet_count and
texture_count are zero on every class examined, and the normals offset
at 0x0c points 117,788,434 bytes into a 16.9 MB lump.

Only the agreed-on prefix is decoded. What makes it trustworthy:

* o_class at 0x44 equals the core index's class number for all 1,864 tie
  classes across all 27 levels. A field landing on the right number that
  often is not a coincidence, and it pins the header base.
* The LOD distances are ordered 0 < near < mid < far for 1,784 of 1,864.
  The 80 exceptions are real, unexplained, and are reported rather than
  asserted away.

Level 0's first tie class has distances 12.0 / 25.0 / 40.0, a plausible
prop LOD band, and packet offsets 256, 20,592 and 26,048.

The rest is deliberately not guessed at. A field order that produces
plausible output and is wrong is the specific failure this project keeps
recording, three times now: the gameplay extent, the tfrag record
framing and the class tables were all "reasonable" and all wrong.

docs/plan/level-assets.md

@@ -593,6 +593,33 @@ At the offsets sit raw GS/VIF packet data, not a further container: moby[0]
 begins `00 00 00 00 3f 16 02 55 6f 6f`, tie[0] `00 01 00 00 70 50 00 00`,
 which read as packet headers rather than a magic number.
 
+### Tie: the class header only partly matches
+
+Tie is the easy one of the three -- instanced static geometry, no skeleton -- so
+it is the right place to start.
+
+RAC1's class header is 0x80 bytes. RAC2 agrees with it over the first `0x48`:
+the per-LOD packet offsets, the three LOD distances and `o_class` all check out.
+From `0x48` on it does not. `lod_info` at `0x50` reads back as noise,
+`packet_count` and `texture_count` are zero on every class examined, and the
+`normals` offset at `0x0c` points 117,788,434 bytes into a 16.9 MB lump.
+
+So only the agreed-on prefix is decoded. The evidence for trusting it:
+
+- **`o_class` at `0x44` equals the core index's class number on all 1,864 tie
+  classes across all 27 levels.** A field landing on the right number that many
+  times is not a coincidence, and it is what pins the header base.
+- The LOD distances are ordered `0 < near < mid < far` for **1,784 of 1,864**.
+  The 80 exceptions are real, unexplained, and are reported rather than
+  asserted away.
+
+Level 0's first tie class has distances 12.0 / 25.0 / 40.0, which is a
+plausible prop LOD band, and packet offsets 256, 20,592 and 26,048.
+
+The remainder is not guessed at. A field order that produces plausible output
+and is wrong is the specific failure this file keeps recording -- the gameplay
+extent, the tfrag record framing and the class tables have all been it.
+
 ### Why the frame is still dark: the light bank does not parse on RAC2
 
 The reference frames the bank as "a u32 offset at +0x04, then an `i32` count