Rule out the moby_anim instance-table reading of the chunk types

moby_anim was the one post-shrub chunk type with a concrete reason to exist: an
instance table would have to scale with the level's moby class count, so
comparing per-type record counts against that count was the obvious test.

It fails, and the way it fails is itself the result: per-type record counts are
level-independent. The same types report the same counts on every level tried:

  type_id     level0  level1  level2  level3
  0x007d7ec438   90      90      90      90
  0x00d3d8c4a9   90      90      90      90
  0x00429ec43d   77      77      77      77
  0x0053c8c4aa   77      77      77      77
  0x007626c4a4   50      50      50      50
  0x00fb88c462   47      47      47      47

Across all 27 levels there are 77 distinct chunk types, the largest at 2430
records total -- exactly 90 x 27.

What that rules out: nothing in this chunk set is a per-moby-class instance table,
because those counts would vary by level the way the moby class counts do. So
whatever holds moby animation data is either keyed by something other than the
class count, or it is not among these chunk types.

Also visible: the types pair up. 0x007d7ec438 and 0x00d3d8c4a9 both report 90 on
every level; 0x00429ec43d and 0x0053c8c4aa both report 77. Two chunk types
carrying identical, constant record counts on every level is a signature of two
views of the same fixed table rather than two independent tables that happen to
agree.

Still open: the pairings are described but not explained, and no type has been
named. The Moby class-ID enrichment from earlier stands separately -- 9493 hits
against 246.1 expected is real, and the class arrays are contiguous per type, but
that identifies where classes are referenced, not which chunk is moby_anim.

docs/plan/level-assets.md

@@ -1693,3 +1693,39 @@ all 27 levels.
 
 What is still not named: what any of the four header words *means*, and how the
 level-specific tail is structured. The module reports them as fields.
+
+### moby_anim: the instance-table hypothesis is out
+
+`moby_anim` was the one post-shrub chunk type with a concrete reason to exist --
+an instance table would have to scale with the level's moby class count, so
+comparing per-type record counts against that count was the obvious test.
+
+**It fails, and the way it fails is itself the result: per-type record counts are
+level-independent.** The same types report the same counts on every level tried:
+
+    type_id     level0  level1  level2  level3
+    0x007d7ec438   90      90      90      90
+    0x00d3d8c4a9   90      90      90      90
+    0x00429ec43d   77      77      77      77
+    0x0053c8c4aa   77      77      77      77
+    0x007626c4a4   50      50      50      50
+    0x00fb88c462   47      47      47      47
+
+Across all 27 levels there are 77 distinct chunk types, the largest at 2,430
+records total -- which is exactly 90 x 27.
+
+**What that rules out.** Nothing in this chunk set is a per-moby-class instance
+table, because those counts would vary by level the way the moby class counts do.
+So whatever holds moby animation data is either keyed by something other than the
+class count, or it is not among these chunk types.
+
+**Also visible: the types pair up.** 0x007d7ec438 and 0x00d3d8c4a9 both report 90
+on every level; 0x00429ec43d and 0x0053c8c4aa both report 77. Two chunk types
+carrying identical, constant record counts on every level is a signature of two
+views of the same fixed table -- one indexed one way and one another -- rather
+than two independent tables that happen to agree.
+
+**Still open.** The pairings are described but not explained, and no type has been
+named. The Moby class-ID enrichment from earlier stands separately: 9,493 hits
+against 246.1 expected is real, and the class arrays are contiguous per type, but
+that identifies *where classes are referenced*, not which chunk is `moby_anim`.