handoff: F5 snap target undecidable within [160,238); the port's 236 is free

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

docs/port/HANDOFF.md

@@ -6240,3 +6240,25 @@ frames; `f6b` holds at median 254.3. That is my phase model drifting, not the
 parent — a varying parent would degrade in both. **Do not use my post-wrap
 decomposition for anything**; a per-cycle phase fit would be needed and I have
 not done it.
+
+## ❔ F5 snap target: `[160,238)`, and it can never be pinned from a capture (`b991a3f`)
+
+`docs/re/f5-snap-target-undecodable-with-reach.md`. **Your 236.0 is free — keep
+it.**
+
+Bound tightened from `[100,238)`: `ptcopyright` goes **absent → α255 in one
+frame** at the snap, skipping its declared 138→160 ramp, so `t ≥ 160`; the sweeps
+are still at α255, so `t < 238`.
+
+**It stops there permanently.** Every build-4 element with a keyframe past
+`t=100` holds a constant pose across `[160,238)` — `ptlogo1/2` static 42→251,
+`ptlogo_tm` 116→242, `pteff00` 16→261, `ptloop01/02` 100→238, `pteff02` 118→236
+at α0, `ptlogo_back2` 80→243, `ptlogo_back2eff` 66→238, `ptcopyright` 160→238.
+Their intersection **is** the window. The game draws a bit-identical frame at
+`t=160` and `t=236`.
+
+So **236.0 can never be confirmed or refuted by any capture**, and it never
+becomes observable later either: the clock freezes at settle, and the `238…250`
+exit plays when the screen *leaves*, not on a timer. Any value in the window
+behaves identically. Your code comment recording it as unconfirmed is right, and
+you can stop treating it as a loose end.