Locate a per-cell offset table in collision, on level 4

Range measured: longest strictly-ascending u32 run (delta under 65536) in each
level's collision payload, levels 0 to 5.

Level 4 is the clean case. Grid 3x25, payload 2660608, and at payload +5932 a
run of 19 entries whose values are all inside the payload, starting at 146012:

  deltas 204, 212, 216, 224, 224, 228, 228

The deltas grow monotonically, which is the signature of a prefix sum over
records of increasing size -- what a per-cell offset table looks like when cell
contents vary.

The others are not:

  level 0  11x33   +21232   17   8193, 24575, 8192, 8192   multiples of 8192,
                                                              coincidental on
                                                              dense data
  level 1  24x16   +41452   29   32771, 57339, 24575        wild, no trend
  level 2   1x53   +13752   49   24, 64, 396, 104          in-region but
                                                              irregular
  level 3  19x31  +667152   18   769, 257, 257, 257        values ~5.2e8, far
                                                              outside the payload
  level 4   3x25    +5932   19   204, 212, 216, 224        growing, in-region

Only level 4's run has both properties a prefix sum needs: values inside the
payload, and deltas that grow.

What this does not give: level 4's run is 19 entries against 75 grid cells, so
it is not one offset per cell -- either most cells share an offset, are empty,
or the table covers something other than the grid. Nothing measured picks between
those.

Next to check: whether 19 relates to 3x25 by any arithmetic, and whether the
same offset at +5932 exists in other levels at a position given by their leading
counts. Neither has been tried.

docs/plan/level-assets.md

@@ -1519,3 +1519,41 @@ is where the per-cell table is likely to start, and it is the next thing to
 resolve.
 
 Exposed as `CollisionHeader::first` and `::second`.
+
+## Collision: a per-cell offset table, located on level 4
+
+**Range measured:** longest strictly-ascending `u32` run (delta under 65,536) in
+each level's collision payload, levels 0 to 5.
+
+**Level 4 is the clean case.** Grid `3 x 25`, payload 2,660,608 bytes, and at
+payload `+5932` a run of 19 entries whose values are all inside the payload,
+starting at 146,012:
+
+    deltas: 204, 212, 216, 224, 224, 228, 228
+
+**The deltas grow monotonically.** That is the signature of a prefix sum over
+records of increasing size, which is what a per-cell offset table looks like when
+cell contents vary.
+
+**The others are not.**
+
+| level | grid | run at | entries | first deltas | verdict |
+|---|---|---|---|---|---|
+| 0 | 11x33 | +21232 | 17 | 8193, 24575, 8192, 8192 | multiples of 8,192 — coincidental on dense data |
+| 1 | 24x16 | +41452 | 29 | 32771, 57339, 24575 | wild, no trend |
+| 2 | 1x53 | +13752 | 49 | 24, 64, 396, 104 | in-region but irregular |
+| 3 | 19x31 | +667152 | 18 | 769, 257, 257, 257 | values ~5.2e8, far outside the payload |
+| 4 | **3x25** | **+5932** | **19** | **204, 212, 216, 224** | **growing, in-region** |
+
+Only level 4's run has both properties a prefix sum needs: values inside the
+payload, and deltas that grow.
+
+**What this does and does not give.** Level 4's run is 19 entries against 75
+grid cells, so it is not one offset per cell -- either most cells share an
+offset, are empty, or the table covers something other than the grid. Nothing
+measured here picks between those.
+
+**The next thing to check** is whether level 4's run length, 19, relates to its
+`3 x 25` grid by any arithmetic, and whether the same offset at `+5932` exists
+in the other levels at a position given by the leading counts. Neither has been
+tried yet.