Ranking the 394 by size is backwards; record the confound

Ranking the moby_classes candidates largest-first is the wrong first cut. The
top entries are 34,316 and 26,432 bytes with 631 and 421 distinct immediates,
median candidate 852.

A function with 631 distinct immediates is far more likely to contain any given
value, 0xc0 included, than one with 80, purely by pigeonhole. Sorting by size
therefore selects for the functions most likely to be false positives, and the
34,316-byte outlier is probably a mis-bounded extent -- the decomp corrects
three level-00 entries -- rather than a 34 KB loader.

The 394 needs a size-independent statistic: whether a function contains 0xc0 more
often than its immediate count predicts, not whether it contains it at all. Not
measured.

Recorded as a negative about the method rather than committed as progress. No test
-- there is no assertion here to make.

283 passing with the disc present, clippy clean.

docs/plan/level-assets.md

@@ -2045,8 +2045,30 @@ and `tie_classes` offsets, so there is no single function that indexes both chun
 tables by immediate. The moby loader, if it exists in this form, does not reach
 the tie table the same way.
 
-**Next step, now concrete:** the 394 is a real shortlist. Take the ones whose
-immediates also include chunk offsets that *do* look like class-table references,
-or the largest ones -- the 34,316-byte outlier is the most promising single
-target -- and disassemble those. That is bounded work, unlike the four probes
-that produced nothing.
+### Ranking by size does not narrow, and biases toward false positives
+
+The obvious next move was to rank the 394 largest-first and start with the
+biggest. Ranked, over 2,323 functions, median candidate size 852:
+
+    0x2ba7d8  34,316 bytes   631 distinct immediates
+    0x2cb3a8  26,432         421
+    0x300618  11,348         155
+    0x3ae900   8,440         208
+    ...                              median 852
+
+**This ranking is probably backwards.** A function with 631 distinct immediates
+is far more likely to contain any given value -- including `0xc0` -- than one with
+80, purely by pigeonhole. Sorting by size therefore selects *for* the very
+functions most likely to be false positives, and the 34,316-byte outlier is
+probably a mis-bounded extent (the decomp corrects three level-00 entries, per
+`docs/LEVELS.md`) rather than a 34 KB loader.
+
+So the 394 needs a size-independent statistic before it is a shortlist. The right
+measure is whether a function contains `0xc0` **more often than its immediate
+count predicts** -- expected count from the neighbourhood rate, observed count
+inside that function -- rather than whether it contains it at all. That has not
+been measured.
+
+Recorded rather than claimed as progress: ranking by size is the wrong first cut,
+and the reason is a confound that would have made the result look better than it
+was.