Characterise gameplay.bin as a flat pointer table, and record volumes as unlocated

Range measured: the first 40 u32 and the whole file, on levels 0 and 1 --
1872256 and 2006400 bytes.

Result: the file is a flat array of u32, opening with a small count then a run of
ascending offsets, terminating on a zero:

  level 0  336 797472 798832 799136  464 150672 150688 314800 479920 ...
           ... 1847600 1845456 797808 1829056 160 1849088 1249808 1847616 0

  level 1  496 799904 800128 800432  624 151152 151168 315680 481456 ...
           ... 1984496 1982400 800112 1966000 160 1988160 1303456 1984512 0

Both levels carry the same shape. The sentinel 160 appears at u32 index 34 on
both and the zero terminator at index 38 on both, with counts 336 against 496
and 464 against 624 at the head. The leading ~38 words are a structured header
whose layout is level-independent apart from its sizes.

The offsets cluster into groups -- near 800000, 150000, 1050000, 1800000 --
which is what a table of pointers into several buffers looks like.

Not decoded: what the pointers point into, what 160 is, and why the zero
terminator sits at the same index on both levels. No gc_formats module exists for
this yet; it is characterised, not parsed.

On volumes: nothing resembling volumes was found here. gameplay.bin is u32
pointers throughout and holds no float data in its first 64 words read as f32 --
59 of 64 are denormals, i.e. small integers reinterpreted. Volumes remain
unlocated on the disc; nothing in the regions examined so far presents itself as
one.

docs/plan/level-assets.md

@@ -1635,3 +1635,36 @@ continuations land on boundaries and read as separate entries.
 `gc_formats` module for it. The `+0x18`/`+0x20` names are section names but
 their structure is not established, and it is not yet shown that they index
 anything.
+
+## gameplay.bin is a flat pointer table
+
+**Range measured:** the first 40 `u32` and the whole file, on levels 0 and 1 --
+1,872,256 and 2,006,400 bytes.
+
+**Result:** the file is a flat array of `u32`, opening with a small count and
+then a run of ascending offsets, and **terminating on a zero**:
+
+    level 0:  336 797472 798832 799136  464 150672 150688 314800 479920 ...
+             ... 1847600 1845456 797808 1829056 160 1849088 1249808 1847616 0
+
+    level 1:  496 799904 800128 800432  624 151152 151168 315680 481456 ...
+             ... 1984496 1982400 800112 1966000 160 1988160 1303456 1984512 0
+
+**Both levels carry the same shape.** The same sentinel value, `160`, appears at
+`u32` index 34 on both, and the zero terminator at index 38 on both, with counts
+336 against 496 and 464 against 624 at the head. So the leading ~38 words are a
+structured header whose layout is level-independent apart from its sizes.
+
+The offsets cluster into groups -- near 800,000, near 150,000, near 1,050,000,
+near 1,800,000 -- which is what a table of pointers into several buffers would
+look like.
+
+**Not decoded.** What the pointers point into, what `160` is, and why the zero
+terminator sits at the same index on both levels. No `gc_formats` module exists
+for this yet; it is characterised, not parsed.
+
+**On volumes.** Nothing resembling volumes was found here. `gameplay.bin` is
+u32 pointers throughout and holds no float data in its first 64 words read as
+`f32` (59 of 64 are denormals, i.e. small integers reinterpreted). Volumes remain
+unlocated on the disc -- nothing in the regions examined so far presents itself
+as one.