port: WITHDRAW 'the plate never blinks' -- it always did, and I tested the wrong property

The pulse has been implemented since 2026-08-30: authored/timing.json
looping_focus_records maps press_start/ptbtn00 -> ptbtn00f at period_units 120,
kind measured. The Decoder's independent figures (120 units, peak 80, ~51 of 60
frames) match the declared record on all three counts.

Verified rather than argued: 502 samples from a filmed boot folded onto the
declared 120-unit period reproduce the declared curve under ONE solved gain --
4.2% rms, with the flat top (phases 36-47, the alpha-80 plateau) and the flat
zero (108-119) both landing where declared. A sine of the same period fits 5.7x
worse, so it is the declared SHAPE and not just the period.

🔴 How I got it wrong: I measured 'does it return to dark'. It never does, BY
DESIGN -- the pulse is an additive glow over a base held at 255. I recorded an
11.6% ripple at a ~120-unit period, which WAS the pulse at exactly its declared
period, and attributed it to background leaking through my glyph mask.

I tested a property the feature was never supposed to have, and the authored
entry said so in its own words before I started. I read the disc's ptbtn00
keyframes, saw 244:0, and never read the port's own configuration for the element
I was measuring.

No code change. The arrival half of the page stands.

docs/port/plate-arrives-on-time-but-never-blinks.md

@@ -1,4 +1,41 @@
-# H3 re-asked after the animation fix: the plate is **on time**, and it **never blinks**
+# ❌ HALF OF THIS PAGE IS WRONG: the plate DOES blink, and always did
+
+> 🔴 **"It never blinks" is refuted, by the port's own code and by measurement.**
+> The pulse has been implemented since **2026-08-30** — `authored/timing.json`
+> `looping_focus_records` carries `press_start/ptbtn00` →
+> `{record_element: ptbtn00f, period_units: 120, kind: measured}`, taken off the
+> running game. The Decoder's independent 2026-09-02 figures (period 120 title
+> units, peak α80, drawn ~51 of 60 frames) match the declared record
+> `0:0 6:6 29:74 35:80 50:80 58:74 97:6 105:0` on all three counts.
+>
+> **Verified now rather than argued.** 502 samples from a filmed boot, folded onto
+> the declared 120-unit period, reproduce the declared curve with **one solved
+> gain**: 4.2 % rms residual against the pulse's own amplitude, and **both flat
+> regions land where declared** — a flat top across phases 36–47 (the α80
+> plateau) and a flat zero across 108–119. A sine of the same period fits
+> **5.7× worse**, so this is the declared *shape*, not merely the right period.
+>
+> ✅ **The port needed no change.** The section below proposed one and held; the
+> hold was right for the wrong reason.
+>
+> ### 🔴 How I got it wrong, which is the part worth keeping
+>
+> I measured **"does it return to dark"**. It never does, *by design*: the pulse
+> is an additive glow over a base plate held at α255, so the total swings between
+> bright and brighter. I recorded an **11.6 % ripple with a ~120-unit period** —
+> the pulse, at exactly its declared period — and attributed it to the title's
+> background sweep leaking through my glyph mask.
+>
+> **I tested a property the feature was never supposed to have.** And the
+> authored entry said so in its own words before I started: *"IT NEVER GOES OFF …
+> while the screen is held the base sits at its own hold and `ptbtn00f`'s cycle
+> runs over it."* I read the disc's `ptbtn00` keyframes, saw `244:0`, and never
+> read the port's own configuration for the element I was measuring.
+>
+> ⚠️ The **arrival** half of this page stands — the plate is on time, and that
+> was measured against declared keyframes rather than against an assumption.
+
+## The original page, kept for the arrival half
 
 **Status:** ✅ **the "arrives late" observation does not reproduce as a timing
 error** — measured on the current build, and the plate's onset sits on its