Range measured: the first four bytes of the payload on all 19 levels that carry
a non-empty one.
Result: two u16 at payload +0 and +2, both non-zero on all 19, ranging 1..74 and
13..112, products 53 to 3256.
level 0 11 x 33 = 363 payload 903248
level 1 24 x 16 = 384 payload 2800496
level 2 1 x 53 = 53 payload 2315296
level 7 40 x 35 = 1400 payload 4049232
level 9 74 x 44 = 3256 payload 2518352
level 13 2 x 64 = 128 payload 3333520
level 26 27 x 112 = 3024 payload 652176
Reported as two counts, not as a named grid. They have the shape of collision
grid dimensions -- bounded, both non-zero, products in the hundreds to thousands
-- but nothing measured ties the product to the payload size or to any per-cell
stride. Level 2's 1 x 53 giving a 2.3 MB payload and level 26's 27 x 112 giving
652 KB shows the product does not size the payload, so either cells vary wildly
in size or these are not grid dimensions. Naming them width and depth would be a
reading, not a measurement.
After the two counts comes a run of u16 that stays below 8192 for 30 to 58
entries depending on level, always an even count, and is not ascending. That is
where the per-cell table most likely starts, and it is the next thing to
resolve.
Exposed as CollisionHeader::first and ::second. They live in the payload rather
than the header, so CollisionHeader::region fills them in and the bare
CollisionHeader::parse leaves them zero -- documented at the call site so the
difference is not mistaken for an absence.