port: the plate pulses -- restore the looping record, over the base rather than instead of it

Ask #1 measured: held at the title with no input the plate oscillates ~23 cycles
per window with no decay and NEVER goes off -- floor 159 thresholded pixels,
pulse bottoming at 714. A glow alone cannot do that (0 -> 80 -> 0); a steady base
plus a pulsing glow can, and 714/1520 are base-only and base-plus-glow.

The port already had the base right: ptbtn00's fade to 0 at t=244 is its EXIT
ramp, and while held the base sits at alpha 255. The glow was missing.

The defect was in the renderer, not the entry I deleted on 2026-08-29. _draw
treated a looping record like a focused one -- drawn INSTEAD of the base, which
is right for a focused button and wrong here. I deleted the right thing for the
wrong reason. A looping record now draws OVER the base and the entry is restored.

Rendered: 95.68 base only, 115.52 at peak, period 1.980 s against a declared 120
units = 2.000 s, ratio 0.990. Visible on the boot path; not under --screen
--overlay, where a static overlay poses at its arrival by design.

Authored in UNITS on their instruction, with their three limits verbatim: one
boot, does not distinguish boot from attract title, and 714/1520 is not an alpha
ratio so no duty cycle is inferred.

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

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-121 sections. Search this before re-deriving anything.
+122 sections. Search this before re-deriving anything.
 
 * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
 * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -132,6 +132,7 @@ dies, which is what this file is for.
 * [A withholding reason that was false, and the measurement beside it that was not](#a-withholding-reason-that-was-false-and-the-measurement-beside-it-that-was-not)
 * [The sweep discriminator resolves: different frames, and a sweep position cannot date one](#the-sweep-discriminator-resolves-different-frames-and-a-sweep-position-cannot-date-one)
 * [Their trap, run against my tree — and I found its mirror instead](#their-trap-run-against-my-tree--and-i-found-its-mirror-instead)
+* [The plate pulses — measured, and the port was wrong on the boot's end state](#the-plate-pulses--measured-and-the-port-was-wrong-on-the-boots-end-state)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -7120,3 +7121,60 @@ correlated-instrument shape I have been careful about all week and did not apply
 to my own message. The discriminator result is unaffected — 294.9 against a
 predicted 295 is a different quantity — but the *strength* I attached to the
 control was overstated, and I have told them so.
+
+## The plate pulses — measured, and the port was wrong on the boot's end state
+
+Ask #1 came back the other way. Held at the title with **no input**, the plate
+oscillates continuously — two windows in one boot, ~23 cycles each, no decay, no
+settling — and 🔴 **it never goes off**: the plate-absent floor is **159**
+thresholded green pixels and the pulse bottoms at **714**, four and a half times
+that.
+
+That reading is what makes the mechanism recoverable. A glow alone cannot do it:
+`ptbtn00f` ramps 0 → 80 → 0. A **steady base plus a pulsing glow** can, and 714 and
+1520 are exactly base-only and base-plus-glow.
+
+And the port already had the base right. `ptbtn00`'s fade to 0 at t=244 is its
+**exit** ramp, which plays when the screen leaves; while the screen is *held* the
+base sits at its own hold, alpha 255 at t=238. What was missing was the glow.
+
+### The defect was in the renderer, not in the deleted entry
+
+`_draw` treated a **looping** record like a **focused** one — drawing it *instead
+of* the base sprite. For a focused button that is right and measured (the focused
+sprite covers the base at 100 % of base-visible pixels). For the plate it
+substituted a dim glow for a bright sprite, which is why the plate vanished and
+why I deleted the authored entry on 2026-08-29.
+
+I deleted the right thing for the wrong reason. The entry was correct; the branch
+it landed in was not. A looping record now draws **over** the base, and the entry
+is restored with the measurement behind it.
+
+| | |
+|---|---|
+| plate region, base only | **95.68** |
+| base + glow at peak | **115.52** |
+| measured period over 10 cycles | **1.980 s** |
+| declared 120 units at 60 u/s | 2.000 s — **ratio 0.990** |
+
+✅ The pulse appears on the **boot** path, where the overlay runs on the shared
+clock. It does *not* appear under `--screen=title --overlay=press_start`, because
+a static overlay poses at its own arrival — my own earlier fix — so its clock never
+advances. That is correct for a still frame and worth knowing before anyone reads
+a flat plate there as a regression.
+
+### What is authored, and what is refused
+
+**120 units, not seconds**, on the Decoder's own instruction: their run measured
+2.530 and 2.540 s and an earlier corpus run 2.24 s — one declared number through
+two emulator pacings (×1.27 and ×1.12 against a nominal 2.000 s). Hardcoding 2.5 s
+would author a loaded container's clock.
+
+⚠️ Their three limits are carried into `authored/timing.json` verbatim: **one
+boot**, two windows inside it are not two boots; it **does not distinguish** the
+boot title from an attract-loop title, since run 1 opens at t≈255 s against Q9's
+~193 s baseline; and 🔴 **714/1520 is not an alpha ratio** — the counter is
+thresholded pixels, so no duty cycle or ramp shape may be read from it. The port
+draws the record's own declared ramp and infers nothing about its shape.
+
+Oracle rows unmoved; every asserting check passes.