port: draw the plate's highlight additive, and find my harness poses it where it cannot be seen

blend-bit-vs-oracle.txt entry 2: ptbtn00 alpha-over, ptbtn00f ADDITIVE -- the
PRESS (A) plate and its own highlight, one bit apart. Entry 4, the whole title, is
alpha-over throughout including ptlogo_back2/ptlogo_back2eff, which independently
kills the "frame-shaped and mostly transparent means additive" rule I declined to
adopt.

Bands are now per DRAW OP rather than per paint-order entry: one band per element
cannot express base alpha-over with its own focus record additive.

The change reported zero three times and each zero had a different cause.

First, additive_elements was assigned to `view` in three places and to `overlay` in
none, and the plate is an overlay -- every other decoded rule on that page goes to
both.

Second, I then measured that the element is never drawn, suppressing its sprite at
six times across the cycle for 0 px every time, and was one commit from filing "the
port never draws the plate highlight" as a defect. That sweep was invalid: I varied
--time while passing --loop-phase=0 in every run, and --loop-phase pins exactly the
clock a looping record runs on. Six samples of one phase.

Third, swept properly, ptbtn00f contributes 0 px at phase 0 and 22-29k px at phases
20-100 -- and verify-capture's title_plate row poses at loop-phase 0. The row that
validates the plate is blind to the plate's pulse by construction. It correctly
reports 13.03 / 0.09 % unchanged while the fix moves 26 319 px at phase 20. Stated
in the tool next to the pose.

Not verified against the oracle: every title-plate capture we hold is at the blind
phase, so no capture here can confirm the port now draws it right. Asked.

docs/port/BLOCKED.md

@@ -155,6 +155,26 @@ quads and the batch holds six, so four were dropped **with a well-formed log lin
 Adopted — EXTRAS whole-screen residual **1.97 → 0.63**, `ptframe4` 31.90 → 1.14.
 See `DECISIONS.md` for the `pteff10` metric split and why I took it anyway.
 
+## New ask, 2026-08-31 — a capture of the title plate at a NON-ZERO loop phase, port `HEAD` `9a8b43e`
+
+**Every title-plate capture we hold is at the plate's blind phase**, so nothing in
+this repository can tell whether the port now draws the plate's pulse correctly.
+
+`ptbtn00f` — the plate's highlight, measured **additive** (entry 2 of
+`docs/re/data/blend-bit-vs-oracle.txt`) — contributes **0 px at loop phase 0** and
+22 000–29 000 px at phases 20–100. `verify-capture` poses `title_plate` at
+`--loop-phase=0`, matching `live-title-press-a.png`. So the row agrees to 0.09 %
+and is **blind to the pulse by construction**, and switching the element to its
+measured blend moved 26 319 px at phase 20 while reporting exactly zero here.
+
+📌 **The blend itself is not in question** — it is theirs and measured off the GPU.
+What is unverifiable on my side is whether *my renderer* now reproduces it. One
+capture of the title with the plate at a visibly mid-pulse instant closes it.
+
+⚠️ Cheap alternative if a fresh capture is expensive: the plate's alpha at a known
+phase, from the existing `plate-pulse-measured.md` run, would let me check the
+level rather than the picture.
+
 ## New ask, 2026-08-31 — three, derived from today's completed blend delivery, port `HEAD` `49a6333`
 
 **1. Is `pteff10` additive on the MAIN MENU too?** It is measured additive on

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 -->
 
-337 sections. Search this before re-deriving anything.
+338 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)
@@ -348,6 +348,7 @@ dies, which is what this file is for.
 * [EXTRAS is complete: 1.97 → 0.63, and the two metrics disagree about it](#extras-is-complete-197--063-and-the-two-metrics-disagree-about-it)
 * [🔴 Refuted: my kind census was a two-screen generalisation, one message after I criticised theirs](#refuted-my-kind-census-was-a-two-screen-generalisation-one-message-after-i-criticised-theirs)
 * [🔴 Refuted: the sweeps DO run on the menu, and my instrument was measuring my own renderer](#refuted-the-sweeps-do-run-on-the-menu-and-my-instrument-was-measuring-my-own-renderer)
+* [The plate's highlight is additive — and my harness poses it at the one phase where it is invisible](#the-plates-highlight-is-additive--and-my-harness-poses-it-at-the-one-phase-where-it-is-invisible)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -16386,3 +16387,48 @@ path, so enabling the loop today would make the port more correct in behaviour a
 visibly worse against the capture. That trade needs the ramp first, and it is
 filed. What has changed today is the *claim*: **the port is wrong here, and says
 so.**
+
+## The plate's highlight is additive — and my harness poses it at the one phase where it is invisible
+
+`blend-bit-vs-oracle.txt` entry 2: `ptbtn00` `0x0110` **alpha-over**, `ptbtn00f`
+`0x0112` **ADDITIVE** — the PRESS Ⓐ plate and its own highlight, same screen, same
+draw order, one bit apart. Entry 4, the whole title, is **alpha-over throughout**,
+including `ptlogo_back2`/`ptlogo_back2eff` — which independently kills the
+*"frame-shaped and mostly transparent ⇒ additive"* rule I declined to adopt.
+
+Bands are now per **draw op** rather than per paint-order entry, because one band
+per element cannot express *base alpha-over, its own focus record additive*.
+
+### 🔴 It reported ZERO three times, and each zero had a different cause
+
+**R2 says a change with a predicted magnitude that delivers nothing is a failed
+run, not a negative result.** This one delivered nothing three times.
+
+1. **The mapping never reached the overlay.** `additive_elements` was assigned to
+   `view` in three places and to `overlay` in **none** — and the plate *is* an
+   overlay. Every other decoded rule on that page is assigned to both.
+2. **I then "proved" the element is never drawn** — suppressed its sprite at six
+   times across the cycle, 0 px every time. ⚠️ **That sweep was invalid.** I varied
+   `--time` while passing **`--loop-phase=0` in every run**, and `--loop-phase`
+   pins exactly the clock a looping record runs on. Six samples of one phase. I
+   was one commit from filing *"the port never draws the plate highlight"* as a
+   defect.
+3. **The real reason the harness saw nothing.** Swept properly:
+
+| loop phase | `ptbtn00f` contributes |
+|---|---|
+| **0** | **0 px** |
+| 20 / 40 / 60 | 28 197 / 28 830 / 28 821 px |
+| 80 / 100 | 27 334 / 21 885 px |
+
+**`verify-capture`'s `title_plate` row poses at `--loop-phase=0`** — the single
+phase where the highlight contributes nothing. The change is live and worth
+**26 319 px** at phase 20, and the row correctly reports 13.03 / 0.09 % unchanged,
+because it is blind to it by construction.
+
+📌 That is a defect in my instrument, not in the fix: **the row that validates the
+plate cannot see the plate's pulse.** Now stated in the tool, next to the pose.
+
+⚠️ **Not verified against the oracle.** The blend is theirs and measured; that the
+*port* now draws it correctly is not something any capture I hold can confirm,
+because every title-plate capture is at the blind phase. Filed.