port: the PRESS A plate comes back after B, and it did not here

The Decoder measured that after B from the menu the plate is re-drawn (daf8f47).
The port landed on a BARE title: _menu_arrive drops the overlay -- correct, the
plate goes with the screen it was measured on -- but nothing put it back, since
_overlay_spec is cleared the instant the overlay is raised and only the boot
sequence ever set it. Confirmed by running it: ten title elements, no ptbtn00.

_rearm_overlay_for reads the declaration out of authored/flow.json's boot step
for that screen rather than naming press_start, so the plate returns by the same
path and shared clock as on boot, with NO new constant. Controlled both ways:
cancel raises it, entering EXTRAS (no overlay declared) raises nothing.

Script steps now carry an elapsed timestamp, without which the port's own press
latency could not be compared to a measured one. With it: B at 1.01 s, title at
1.37 s = 0.36 s, against their measured <= 0.4 s -- nothing was fitted to that.

The plate's RETURN time does not agree: 4.33 s here against their 7.3 s to pulse,
of which up to 2 s is pulse-detection phase. Not adjusted -- an authored delay in
this same block was already refuted once. Recorded as an ask.

auto_repeat and title/on_cancel upgraded to MEASURED on their run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

docs/port/BLOCKED.md

@@ -753,7 +753,7 @@ maximum adjacent-sample step of **212** against a 99.9th percentile of **3 737**
 so the join is not a click. **It does not discriminate the two readings** — a cut
 near a zero crossing is smooth wherever it falls.
 
-### Ⓑ on the title — what happens, actually measured
+### ~~Ⓑ on the title — what happens, actually measured~~ — ANSWERED 2026-08-30
 
 **Derived from HANDOFF `9ca1eb5`; Decoder branch `86a8ce7`.**
 
@@ -770,7 +770,7 @@ request for a method.
 default and the port ships it either way, so nothing is blocked — this is a
 provenance repair, not a stall.
 
-### Auto-repeat on a held direction
+### ~~Auto-repeat on a held direction~~ — ANSWERED 2026-08-30: none
 
 **Derived from HANDOFF `9ca1eb5`; Decoder branch `86a8ce7`.**
 
@@ -795,3 +795,18 @@ gives the quad's ramp as 10 units (0.17 s); 10 + your 10-14 = 20-24 units =
 constant is needed anywhere and my 9 is simply the wrong side of your boundary.
 The two readings differ in whether a screen is still drawing during the last
 0.2 s.
+
+### How long after Ⓑ does the `PRESS Ⓐ` plate come back?
+
+**Derived from Decoder `daf8f47`.**
+
+They measured press 351.2 s -> pulse back 358.5 s, i.e. **7.3 s**. The port
+raises the plate on arrival and its own group takes it opaque at t=238, giving
+**press -> plate visible 4.33 s**. Pulse detection can lag first paint by up to
+one 120-unit period (2 s), which closes the gap to ~6.3 s at most and leaves
+roughly a second unaccounted for.
+
+**The ask:** is 358.5 s the plate's FIRST paint or the first pulse peak your
+detector could see? If the latter, what is the first-paint time? I am not
+authoring a delay to close this - a `2.13 s` authored delay in this same block
+was already refuted once by arithmetic.

docs/port/DECISIONS.md

@@ -8448,3 +8448,63 @@ is wrong rather than tune until they match — and here the game measurement sho
 win over the draw-stream one on principle, but the gap is small enough that it
 could equally be where each puts the boundary between ramp and hold. It goes to
 `BLOCKED.md` as an ask, at the value it was measured at.
+
+## The plate came back in the game and not in the port
+
+The Decoder's Ⓑ run answered both my asks and threw in a third finding: **after Ⓑ
+from the menu the `PRESS Ⓐ` plate is re-drawn** — pressed 351.2 s, pulse back
+358.5 s (`daf8f47`).
+
+🔴 **The port did not do that.** Ⓑ landed on a *bare* title. `_menu_arrive()`
+calls `_drop_overlay()` — correct, the plate goes with the screen it was measured
+on — but nothing ever put it back: `_overlay_spec` is cleared the instant the
+overlay is raised, and only the boot sequence ever set it. Confirmed by running
+it, not by reading: the drawn list was the ten title elements with no `ptbtn00`.
+
+✅ Fixed. `_rearm_overlay_for(name)` looks the declaration up in
+`authored/flow.json`'s **boot step for that screen** rather than naming
+`press_start`, so the plate returns by the same code path and the same shared
+clock as on boot, and a screen that gains an overlay later gets it on both paths
+with no edit here. **No new constant** — the delay is not authored, it is
+whatever the boot already does.
+
+Controlled both ways: Ⓑ → `overlay press_start raised`, drawing `ptbtn00`,
+`ptbtn00f`; entering `EXTRAS`, which declares no overlay, raises **nothing**.
+
+### An independent agreement I did not tune for
+
+The script log had no press timestamp, so the port's own latency could only be
+guessed from surrounding lines. Added one. With it:
+
+| | |
+|---|---|
+| Ⓑ pressed | 1.01 s |
+| title arrives, overlay armed | 1.37 s |
+| **port's press → title** | **0.36 s** |
+| **their measured Ⓑ latency** | **≤ 0.4 s** |
+
+✅ That agreement is worth something because **nothing here was fitted to it** —
+the port's transition timing comes from the screens' own fade keyframes, and this
+is the first time the two numbers have been put beside each other.
+
+### 🟡 The plate's return time does not agree, and I am not adjusting it
+
+The plate is raised on arrival and its own group takes it opaque at t=238
+(3.97 s), so the port's **press → plate visible ≈ 4.33 s**. Theirs is **7.3 s to
+the pulse**. The pulse has a 120-unit (2 s) period, so pulse *detection* can lag
+first paint by up to 2 s — which closes it to ~6.3 s at most and leaves roughly
+**a second unexplained**.
+
+⚠️ It would be easy to author a delay that makes 4.33 into 7.3. That is exactly
+the tuning this corpus keeps warning about, and the previous authored delay in
+this very block (`after_settle_seconds: 2.13`) was already refuted once by
+arithmetic. Left alone; recorded as an ask.
+
+### Two stamps upgraded, both now measured for real
+
+* `navigation.auto_repeat` — a 2.0 s held ⬇ moves the cursor **once**, their
+  counter passing its control first. Was a consequence of edge-triggered
+  `_input`; now a measurement.
+* `title/on_cancel` — Ⓑ on a **settled** title does nothing, twenty seconds
+  confirmed. This cell has now been `MEASURED` (wrongly), `AUTHORED` (honestly),
+  and `MEASURED` (truly), with the value `null` the whole way through.