Record that tie does not reuse moby's part table

Checked the obvious hypothesis -- that tie, being the other class-geometry
table, would share moby's part-table format -- and it does not.

The tiling rule vertex_offset + 16 * vertex_count == next_part holds for
0 of 25,024 records across the 1,864 tie spans, against 43,467/43,467 for
moby. Tie's second field also reads as an absolute offset rather than a
span-relative one, which is the first sign the record shape differs.

Past the verified 0x48-byte header the bytes are f32-shaped rather than
the expected VIF marker, but they are not a fixed array either: the run of
consecutive plausible floats varies from 1 to 6 across spans (822 spans
have 6, 455 have 1, 373 have 2). So there is more header past 0x48 and
it is not one array of distances -- the floats after that point are a
different population from the LOD distances before it, including negative
values.

Recorded so the next attempt starts from that rather than re-trying the
moby template.

docs/plan/level-assets.md

@@ -854,3 +854,24 @@ The header does self-identify in two places, both exact across all 358 spans:
 constant marker and carries no structural weight. The header is otherwise
 undecoded: the first 0x20 bytes are packed data rather than floats, despite
 `+0x10` landing exactly on 5.0.
+
+## Tie geometry (2026-10-11)
+
+Tie does **not** reuse moby's part-table format. The rule
+`vertex_offset + 16 * vertex_count == next_part` holds for **0 of 25,024**
+records tried across the 1,864 tie class spans, against 43,467/43,467 for
+moby. Tie's second field also reads as an absolute offset rather than a
+span-relative one, which is the first sign the record shape differs.
+
+At `+0x48`, where the verified header currently ends, the bytes are f32-shaped
+(10.0, 40.0, 50.0, 4.0, -100.0, -25.0, 5.0, 3.125), not a VIF marker as
+expected. They are not a fixed-size array either: the run of consecutive
+plausible floats varies from 1 to 6 across spans, with 822 spans having 6,
+455 having 1 and 373 having 2. So there is more header past `0x48`, and it
+is not a single array of distances.
+
+Note the LOD distances already decoded sit *before* this point (12.0, 25.0,
+40.0 at `+0x10`), and the floats after `0x48` are a different population --
+negative values, and a repeated leading 40.0.
+
+Unresolved. The packet geometry remains the open question, unchanged.