Fix the collision grid dims, and disprove two sample artifacts in the payload

With the payload confirmed verbatim in RAM, the disc bytes can be read directly.
The grid dimensions are the first two u16 of the payload: level 0 is 11 x 33 =
363 cells, level 1 24 x 16 = 384, level 2 1 x 53 = 53. Level 2 being one cell wide
is worth noting -- the grids are not all similar in shape.

Two readings disproved, both by measuring the whole payload instead of a sample.

An ascending u32 offset table. A probe from payload +1024 reads f4ae0000 40af0000
c4b2000020b20000, which is three ascending values before the fourth goes down
(0xb2c4 to 0xb220). Read as a table, that was a three-value impression. Scanning
all three levels for maximal ascending u32 runs of 8 or more entries finds zero,
on every level.

A global alternating-zero stride. The head of level 0 shows an obvious (value, 0)
pattern from about i16[37]:

  [32..] [1808, 1872, 2198, 0, 34, 86, 25848, 1, 25824, 1,
         -13028, 0, -12284, 0, -12228, 0, -12716, 0, ...]

Measured over the whole payload, both alignments score far below what that sample
suggests: even-slot aligned 18% second-half zero, odd-slot aligned 13%. The
sample again.

What the global numbers do say is that the payload is heavily zero-bearing -- 18%
against a chance rate of about 0.0015% -- which is what a sparse or variable-length
encoding looks like, and consistent with the variable-length reading established
earlier. The 18-against-13 split is a real alignment preference but a weak one.

The cell layout is still undecoded. The useful position now is that the bytes can
be read as they are and that they are sparse and variable-length rather than
fixed-stride, so the next attempt should look for a terminator-delimited walk
through the sparse region rather than for a record size.

docs/formats/core-data-regions.md

@@ -1642,3 +1642,40 @@ commit concluded from the disc alone. Reading the header word at `+0x00` as an
 element count gave 0 of 922 blocks dividing; it is the byte offset to the payload,
 so the table it bounds has 16-byte records. The number was right and the reading
 was wrong, which is the error the packet-header identification corrected.
+
+## Collision payload: what the verbatim mapping settles, and what it does not
+
+With the payload confirmed verbatim in RAM, the disc bytes can be read directly.
+The grid dimensions are the **first two `u16`** of the payload -- level 0 reads
+**11 x 33 = 363 cells**, level 1 **24 x 16 = 384**, level 2 **1 x 53 = 53**.
+Level 2 being one cell wide is worth noting; the grids are not all similar in
+shape.
+
+**Disproved this round -- an ascending `u32` offset table.** A probe from payload
+`+1024` reads `f4ae0000 40af0000 c4b2000020b20000 ...`, which is three ascending
+values before the fourth goes *down* (`0xb2c4` to `0xb220`). Read as a table that
+was a three-value impression. Scanning all three levels for maximal ascending
+`u32` runs of 8 or more entries finds **zero**, on every level.
+
+**Disproved this round -- a global alternating-zero stride.** The head of level 0
+shows an obvious `(value, 0)` pattern from about `i16[37]` onward:
+
+    [32..] [1808, 1872, 2198, 0, 34, 86, 25848, 1, 25824, 1,
+           -13028, 0, -12284, 0, -12228, 0, -12716, 0, ...]
+
+Measured over the whole payload rather than the first 96 values, both alignments
+score far below what that sample suggests:
+
+    even-slot aligned: second half zero on 18% of pairs
+    odd-slot aligned : second half zero on 13% of pairs
+
+The sample again. What the global numbers *do* say is that the payload is heavily
+zero-bearing -- 18% against a chance rate of about 0.0015% -- which is what a
+sparse or variable-length encoding looks like, and is consistent with the
+variable-length reading established earlier. The 18-against-13 split is a real
+alignment preference but a weak one.
+
+**Still not decoded.** The cell layout. The useful position now is that the bytes
+can be read as they are, and that they are sparse and variable-length rather than
+fixed-stride -- so the next attempt should look for a terminator-delimited walk
+through the sparse region, not for a record size.