re: F5 snap target is [160,238) and cannot be pinned from any capture

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.
Its identification is measured: in the control it first draws at t~143 and
reaches 255 at t~164 against a declared 138->160.

It stops there for a reason worth recording. Every build-4 element with a
key past t=100 holds a constant pose across [160,238) -- their intersection
is exactly that window -- so the game draws a bit-identical frame at t=160
and t=236.

Refutation attempt on the port's 236.0: not merely survives, it can never be
confirmed or refuted by capture. Every value in the window is
observationally identical, and it stays that way because the clock freezes
at settle and the exit ramp plays on leave rather than on a timer.

Classified undecodable-with-reach so nobody spends another run on it.

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

docs/re/f5-snap-target-undecodable-with-reach.md

@@ -0,0 +1,60 @@
+# F5 — the snap target is `[160,238)` and **cannot be pinned from any capture**
+
+**Question:** what title time does Ⓐ jump the clock to?
+
+**What the human looks at:** nothing — this is a negative, and its value is that
+it stops anyone spending another run on it.
+
+**What this does NOT cover:** the per-cycle phase fit, F6.
+
+**Classification: ❔ undecodable, with reach.** ⟨capture⟩ + ⟨disc⟩.
+
+## The bound tightened to `[160,238)`
+
+`ptcopyright.t32` declares `0(α0) · 138(α0) · 160(α255) · 238(α255) · 244(α0)`,
+and in the press run it goes **absent at f435 → α255 at f436**, skipping its
+whole 22-unit ramp. So **t ≥ 160**.
+
+Its identification is measured, not assumed: in the no-input control it first
+draws at **t≈143** and reaches α255 at **t≈164**, against a declared 138→160.
+
+The sweeps are at α255 at the same frame, and their parents' exit runs 238→250,
+so **t < 238**.
+
+## Why it stops there — nothing on the screen changes inside that window
+
+Every element in build 4 with a keyframe past `t=100`, and where it is static:
+
+| element | keys | static across |
+|---|---|---|
+| `ptlogo1` / `ptlogo2` | 0,26,34,38,40,42,**251**,264 | 42→251 |
+| `ptlogo_tm` | 0,98,**116**,**242**,248 | 116→242 |
+| `pteff00.prm` | 0,**16**,**261**,269 | 16→261 |
+| `ptloop01` / `ptloop02` | 0,70,**100**,**238**,250 | 100→238 |
+| `pteff02.prm` | 0,46,61,76,**118**,**236** | 118→236 (α0 both ends) |
+| `ptlogo_back2` | 0,66,**80**,**243**,249 | 80→243 |
+| `ptlogo_back2eff` | 0,62,**66**,**238**,244 | 66→238 |
+| `ptcopyright` | 0,138,**160**,**238**,244 | 160→238 |
+| `pteff01`, `ptlogo_back2eff5`, `ptlogoall_eff`, `ptlogoall_eff2` | last key ≤118 | — |
+
+**Their intersection is exactly `[160,238)`.** The game draws a bit-identical
+frame at `t=160` and at `t=236`. No capture can separate them, because there is
+nothing left that moves.
+
+## Refutation attempt — the port's `236.0`
+
+I tried to refute it and **cannot**, but the finding is stronger than "survives":
+**236.0 can never be confirmed or refuted by a capture.** Every value in
+`[160,238)` is observationally identical, so their choice is free.
+
+Nor does it become observable later: the clock **freezes** at settle
+([`ui-clock-freezes-at-settle.md`](structures/ui-clock-freezes-at-settle.md)), and
+the `238…250` exit plays **when the screen leaves, not on a timer** — so a
+different starting `t` inside the window produces no difference at any point.
+
+## Not settled
+
+* The exact value, permanently, from this route. Only guest memory or the code
+  that performs the assignment could give it, and that is a different instrument
+  than any capture.
+* The per-cycle phase fit for the post-wrap decomposition.