re: F5 code route -- not settled, plus a bounded negative on literal targets

The brief asks for two routes and I had only run the capture. This runs the
code route far enough to record an honest failure: the title's phase 2 and 3
handlers dispatch through vtables on nearly every branch, so finding the
clock write statically needs indirect-call resolution this container does
not do cheaply.

What the scan does establish: over 0x821C4000-0x821CD000 there is no
`li rN,<v>` for any v in 160..250, against a control of 684 li instructions
in the same range. So the snap target is computed or data-derived, not a
literal in the title's code.

Refutation aimed at my own capture result: a literal would have NAMED the
target and refuted "unpinnable from any capture". None exists, so that claim
survives and gains a second reason.

Names the instrument that would settle it: a write-watch on the clock field
in Canary, which would also close "which function advances the clock".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/re/f5-code-route-no-literal-target.md

@@ -0,0 +1,63 @@
+# F5, the code route — ❔ not settled, with one bounded negative
+
+**Question:** does the code handling Ⓐ on the title assign a target time, or
+raise a rate multiplier?
+
+**What the human looks at:** nothing directly — this is the cross-check the brief
+asks for, that the capture's answer is right for the right reason.
+
+**What this does NOT cover:** F6, and the capture route, which is settled
+([`f5-verified-with-full-quad-reader.md`](f5-verified-with-full-quad-reader.md)).
+
+**Instrument:** ⟨image⟩ via `tools/ppc-dis`.
+
+## ❔ I did not find the instruction
+
+The brief asks for two routes. The capture route is done; **this one is not**, and
+I am recording that rather than dressing a partial result as an answer.
+
+Where I looked: the five `GamePart_Title` phase handlers
+([`boot-config-and-gamepart-registry.md`](boot-config-and-gamepart-registry.md)) —
+`sub_821C5690`, the inline phase 1, `sub_821C5818`, `sub_821C5EC0`,
+`sub_821C6458`. Phases 2 and 3 dispatch through vtables (`mtspr`/`bctr`) on almost
+every branch, so following the clock write statically means resolving indirect
+calls, which this container's tooling does not do cheaply.
+
+## ✅ What the scan does establish
+
+**No literal time constant in the range exists.** Over `0x821C4000–0x821CD000`,
+for every value 160…250:
+
+```
+li rN, <v>  for v in 160..250  :  none
+```
+
+Control: the same scan finds **684** `li` instructions in that range, commonest
+values 0, 1, small integers and address halves — so the scan sees `li` fine, and
+the absence is about the values, not the method.
+
+**So the snap target is computed or read from the loaded bundle, not written as a
+literal in the title's code.**
+
+## Refutation attempt — against my own capture result, and it survived
+
+[`f5-snap-target-undecodable-with-reach.md`](f5-snap-target-undecodable-with-reach.md)
+says the target is somewhere in `[160,238)` and unpinnable from any capture. A
+literal in the code would have **named** it and refuted the "unpinnable" framing
+outright. There is none.
+
+That leaves the capture claim standing **and gives it a second reason**: a
+data-derived target has no constant to find, which is consistent with it landing
+inside the one window where nothing observable changes.
+
+⚠️ Reach of this negative: one address range, one instruction form, one tool. A
+float in `.rdata`, a value computed at runtime, or a handler outside
+`0x821C4000–0x821CD000` would all escape it.
+
+## What would settle it
+
+A **write-watch on the UI group's clock field** in Canary — `/canary` is
+read-write and the draw logger already proves the pattern. That names every
+writer, including the snap, and would also close the standing "which function
+advances the clock" question. It is a real instrument, not a bigger search, and
+it is the next thing to build here.