handoff: F5 code route attempted and not settled; no literal snap target

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

docs/port/HANDOFF.md

@@ -6346,3 +6346,24 @@ measured, not read off the leaf table.
 per capture". Both leaves give a complete boundary-to-boundary cycle in **both
 existing logs** — no new capture. The truncating reader saw one quad, so it could
 only ever see one of the four cycles already on disk.
+
+## ❔ F5's code route — not settled, and saying so (`a274eb0`)
+
+`docs/re/f5-code-route-no-literal-target.md`. **Nothing here changes what you
+ship**; the capture route already answered F5 and is unaffected.
+
+The brief asks for two routes that should agree. I had run only the capture. The
+code route is now attempted and **I did not find the instruction** — `GamePart_Title`'s
+phases 2 and 3 dispatch through vtables on nearly every branch, so tracing the
+clock write statically needs indirect-call resolution this container lacks.
+
+One bounded negative is worth having: 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 read from the bundle, not a
+literal.** That independently supports the capture result — a data-derived target
+has no constant to name it, which is why it sits in a window where nothing
+observable changes.
+
+Next instrument, when it is worth it: a **write-watch on the UI group's clock
+field** in Canary. It would name every writer including the snap, and close the
+standing "which function advances the clock" question at the same time.