r2 is never written in the enclosing function, and it has no callers

The trace eca1a16 asked for. The call site 0x3a7d88 sits in the function at
0x3a7c30, 580 bytes.

r2 is never written there: scanning all 580 bytes for any instruction storing into
r2 finds none. So it arrives from outside the function.

And 0x3a7c30 has no jal callers anywhere in level-0 .text, and is not a lvl.vtbl
handler -- level 0's vtbl has 233 records and 185 distinct handlers, and neither
0x3a7c30 nor 0x3a8060 is among them.

That rules out the tidy story, which was the obvious guess given r2 arrives
unexplained: the vtbl dispatcher calling it with a class pointer in v0. What
remains is an indirect jalr call, a dispatch table in data, or code that is never
called. Not distinguished; the question for anyone continuing is whether
0x3a7c30 is a jalr target and from where.

The chain is now ? -> 0x3a7c30 (no static caller) -> 0x3a8060 -> addiu r17, r18,
0xc0. Every remaining question is about control flow and register provenance, not
counts, which is where this stretch's method stops working.

284 passing with the disc present, clippy clean.

docs/plan/level-assets.md

@@ -2240,3 +2240,31 @@ even its use, say nothing about what it means. Six rounds of counting produced o
 robust fact -- `0xc0` is used far more than adjacent constants -- and not one
 identified function. A single disassembly settled in twelve instructions what six
 counting passes could not, and immediately complicated the answer.
+
+### Provenance: r2 is never written, and the enclosing function has no callers
+
+The trace `eca1a16` asked for. The call site `0x3a7d88` sits inside the function
+at `0x3a7c30`, 580 bytes, 145 instructions.
+
+**`r2` is never written in that function.** Scanning every instruction for one
+that stores into `r2` (`sw` or `sb` with `rs == 2`) finds none across all 580
+bytes. So `r2` at the `jal 0x3a8060` is not defined anywhere in the enclosing
+function -- it arrives from outside.
+
+**And `0x3a7c30` has no `jal` callers.** Scanning the whole of level-0 `.text`
+for `jal` instructions targeting it finds zero. It is also **not** a `lvl.vtbl`
+handler: level 0's vtbl has 233 records and 185 distinct handler addresses, and
+neither `0x3a7c30` nor `0x3a8060` is among them.
+
+That rules out the tidy story -- "the vtbl dispatcher calls it with the class
+pointer in `v0`" -- which was the obvious guess given `r2` arrives unexplained.
+The remaining possibilities are an indirect call through a pointer (`jalr`), a
+dispatch table in data rather than in the vtbl, or code that is not called at all.
+
+Not distinguished. The immediate question for anyone continuing is whether
+`0x3a7c30` is a target of any `jalr` in the level, and if so from where.
+
+**This is the end of what counting can do here.** The chain is now:
+`? -> 0x3a7c30 (no static caller) -> 0x3a8060 -> addiu r17, r18, 0xc0`, with `r2`
+supplied by whatever reaches `0x3a7c30`. Every remaining question is about
+control flow and register provenance, not about counts.