Fix the immediate scan by filtering on opcode; still no signal

Saying the previous method 'cannot tell' was right but the reason deserved a step
rather than a hand-wave: it is fixable by counting immediates only where they are
immediates, which needs an opcode filter and no disassembler.

All 27 levels: 11,911,320 instructions, 2,985,897 carrying an immediate
(addiu/lui/ori/xori/andi/sltiu), 13,813 distinct immediate values.

    moby_classes 0x00c0   17,699
    tie_classes  0x1e80       17

And now there is a control the raw version never had -- the program's most
frequent immediates are 0x0001 (200,784), 0x001b (149,259), 0x0010 (137,523),
0xffff (98,312). 0xc0 at 17,699 sits below the top of that small-value cluster
rather than standing out, so it is not a distinctive reference.

Result unchanged from the raw scan and now defensible: no signal. The loader is
not findable by frequency, and the remaining route is structural dataflow --
functions touching both the chunk offset and a class span.

No test: asserting that an offset is unremarkable is not an invariant worth
locking, and the two numbers are already recorded with their denominator.

docs/plan/level-assets.md

@@ -1956,7 +1956,29 @@ whole scan is confounded by value frequency, which is rule 3a again, one level
 below where it has bitten before -- not the measurement being wrong but the
 *comparison* having no shared denominator.
 
-Doing it properly means decoding instructions and counting immediates only where
-they are immediates, which is what `tools/overlay-anchors` is for. Until that
-exists the answer is not "moby_classes is referenced more" or "less", it is
-"this method cannot tell".
+Doing it properly means counting immediates only where they are immediates.
+
+**Done, and it needs no disassembler** -- filter on opcode and take bits 15..0.
+Counting only instructions that carry an immediate (`addiu`, `lui`, `ori`,
+`xori`, `andi`, `sltiu`) across all 27 levels: 11,911,320 instructions,
+2,985,897 with an immediate, 13,813 distinct immediate values.
+
+    moby_classes 0x00c0   17,699
+    tie_classes  0x1e80       17
+
+Now the comparison has a denominator, and it has a control that the previous
+version lacked: the most frequent immediates in the whole program are
+
+    0x0001  200,784     0x0010   137,523     0x0004   57,248
+    0x001b  149,259     0xffff    98,312     0x0002   64,450
+
+So 0xc0 at 17,699 is *below* the top of the small-value cluster rather than
+distinctive. The previous commit's "this method cannot tell" was right, and the
+reason was worth one more step rather than a hand-wave: the method was fixable by
+filtering on opcode, which costs nothing and needs no capstone.
+
+**Result: still no signal.** Nothing in the immediate stream points at
+`moby_classes` more than at the other small offsets the program uses. The loader
+is not findable this way, and the remaining route is structural -- finding
+functions that touch both the chunk offset and a class span, which means real
+dataflow rather than a frequency count.