Volumes: the reference that did not generalise

Last commit said what would settle the volume candidate and implied one of those
was available. They are not. Recording the failure rather than moving on quietly.

Level 0's data.bin -- the level's file descriptor -- contains the value 799204
exactly once, at 0xab6360, and 799204 is byte-for-byte the offset of the 20-record
144-byte candidate table. A single 4-byte match in 13.3 MB has a chance
expectation of ~0.003, so it was worth checking rather than assuming.

It does not hold up. Each level's own best 144-byte table, searched in that same
level's own data.bin:

    level  candidate   records   refs (chance ~0.0035)
      0    1,810,724      32      0
      1    1,884,884     386      0
      2    2,066,804     224      0
      3    2,438,228     365      0
      4    2,677,780     114      0
      5    1,255,780      14      0
      6    2,496,020     115      0
      7    2,062,072     311      0

None. The level 0 hit at 0xab6360 also sits among high-entropy neighbours, and
level 0's own BEST table -- a different offset, 32 records, not the 20-record one
-- is not referenced either. So the hit does not generalise and is most likely
coincidence.

This retracts what the previous commit implied. Nothing links a 144-byte float
table to volumes: the table is reached by walking structure rather than by an
explicit pointer, so the discriminator I named does not exist, and the candidate
stands exactly where it did.

Recording the three routes that would actually settle it, all of them
unavailable: the game's own volume code (same dead end as the collision anchor
-- a GP-relative string search returns nothing); ground truth, such as a count of
level 0's trigger volumes from a map; or a correlation with a named class, since
gameplay.bin resolves ids through its dispatch records -- but no class name
containing "volume" exists on the disc, which is exactly why this is unavailable.

No test added, because there is no solid claim here to assert. 240 tests,
unchanged.

docs/formats/core-data-regions.md

@@ -2245,3 +2245,46 @@ Both were mine, and both produced confident nonsense before being caught.
 The same shape as every other correction in this log: a clean, small, plausible
 number read as conclusive because it was not checked against a control that
 could have disagreed.
+
+### The reference that did not generalise
+
+Level 0's `data.bin` -- the level's file descriptor -- contains the value
+`799204` exactly once, at `0xab6360`, and `799204` is byte-for-byte the offset
+of the 20-record candidate table above. A single 4-byte match in 13.3 MB has a
+chance expectation of about 0.003, which is suggestive enough to be worth
+checking properly rather than assuming.
+
+It does not hold up. Taking each level's own best 144-byte table and searching
+that level's own `data.bin`:
+
+    level   candidate offset   records   references found (chance ~0.0035)
+      0        1,810,724          32      0
+      1        1,884,884         386      0
+      2        2,066,804         224      0
+      3        2,438,228         365      0
+      4        2,677,780         114      0
+      5        1,255,780          14      0
+      6        2,496,020         115      0
+      7        2,062,072         311      0
+
+Not one of the eight is referenced. The level 0 match at `0xab6360` sits in a
+neighbourhood of high-entropy bytes, and level 0's own *best* table -- a
+different offset, 32 records, not the 20-record one -- is not referenced either.
+So the single hit does not generalise and is most likely coincidence.
+
+The consequence is worth stating plainly because it retracts what the previous
+section implied: **nothing links a 144-byte float table to volumes.** The table
+is reached by walking structure rather than by an explicit pointer, so the
+approach that would have settled it does not work, and the candidate stands
+exactly where it did.
+
+What would settle it, and none of these are cheap:
+
+  * The game's own volume code, which has the same byte-order problem as the
+    collision anchor did -- a GP-relative string search returning nothing.
+  * Ground truth: a count of level 0's trigger volumes from a map or a guide,
+    to match against a table's population.
+  * A correlation with a *named* class, since `gameplay.bin` resolves ids
+    through its dispatch records. If an id in the candidate resolved to a class
+    whose name is a volume trigger, that would be decisive. No class name
+    containing "volume" exists on the disc, which is why this is not available.