Correct the overlay strings from a table to a pool

The previous commit described a "debug string table on 16-byte alignment". It is
not a table. Dumping the 32 bytes before each run shows most are the tail of the
previous string:

  +3104  "host0:r:/rc2/shock/wavetable.bin"   32 chars
  +3120  "ck/wavetable.bin"                   its own tail
  +3152  "/i5/shock/wavetable1.bin"
  +3168  "ble1.bin"                           its own tail

and the 32-byte prefixes are 327 distinct out of 332 -- essentially all different,
because they are just the preceding string's bytes. There is no per-record header
here. It is one contiguous pool of debug text, and the 16-byte alignment is a
property of how the pool was laid out, which makes continuations land on
boundaries and read as separate entries.

The count of 332 "strings" was therefore inflated by the same effect: it counts
continuations as entries.

The substance is unchanged and still useful -- the pool carries the game's own
debug text, including "Camera_CollPrimTest WARNING! - grid out of bounds! (RAR)",
which is direct evidence for reading the collision payload's two leading u16 as
grid dimensions, and the wavetable.bin paths, which bear on the sound bank
framing. Only the framing was wrong.

The pool is located and counted but not parsed, and there is no gc_formats module
for it. The +0x18/+0x20 names are section names but their structure is not
established, and it is not shown that they index anything.

docs/plan/level-assets.md

@@ -1595,7 +1595,7 @@ now has one: a header naming two sections, and a string table.
 `u32@+0x00` is **1,735,808 on all three levels**, `+0x08` is `1`, and the bytes
 at `+0x18` and `+0x20` spell **"crap"** and **"system misc"**.
 
-**Result 2 -- a debug string table on 16-byte alignment.** 332 such strings on
+**Result 2 -- a debug string pool, 16-byte aligned.** 332 printable runs on
 level 0, 362 on level 1, 351 on level 2, the first at `+0x20` and the last
 between 1.3 MB and 2.5 MB. They are the game's own debug text:
 
@@ -1616,8 +1616,22 @@ are worth continuing to treat as grid dimensions despite not sizing the payload.
 The `wavetable.bin` paths also confirm the sound bank is loaded from named
 files, which bears on the `SBlk`/`DAW` framing.
 
-**Not done.** The string table is located and counted but not parsed -- the
-records preceding each string have not been identified, so there is no
-`gc_formats` module for it yet. The `+0x18`/`+0x20` names are section names but
+**Correction to the framing above.** This was first written up as a *string
+table* of records. It is not. Dumping the 32 bytes before each run shows most of
+them are the tail of the previous string:
+
+    +3104  "host0:r:/rc2/shock/wavetable.bin"   (32 chars)
+    +3120  "ck/wavetable.bin"                   -- its own tail
+    +3152  "/i5/shock/wavetable1.bin"
+    +3168  "ble1.bin"                           -- its own tail
+
+and the 32-byte prefixes are **327 distinct out of 332**, i.e. essentially all
+different, because they are just the preceding string's bytes. There is no
+per-record header here. It is one contiguous pool of debug text, and the
+16-byte alignment is a property of how the pool was laid out, which makes
+continuations land on boundaries and read as separate entries.
+
+**Not done.** The pool is located and counted but not parsed, and there is no
+`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.