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.

tools/port/verify-capture

@@ -129,6 +129,17 @@ MAP=(
   # independent captures fit at two DIFFERENT phases -- this one at 237, the
   # no-plate one at ~400 -- and both to 0.01 % or better. A geometry error in how
   # the sweeps are drawn would leave a floor in both. Neither has one.
+  # 🔴 THIS ROW IS POSED AT THE PLATE'S BLIND PHASE, and it cannot see the plate's
+  # highlight at all. `--loop-phase=0` pins the looping-focus clock, and
+  # `ptbtn00f` -- the plate's own highlight, which the GAME draws ADDITIVE
+  # (docs/re/data/blend-bit-vs-oracle.txt, entry 2) -- contributes EXACTLY 0 px at
+  # phase 0 and 22 000-29 000 px at phases 20..100. Measured 2026-08-31 by
+  # shadowing its sprite and diffing.
+  #
+  # So switching that element to its measured additive blend moved 26 319 px at
+  # phase 20 and reported ZERO here. This row's 0.09 % is real and unaffected; it
+  # simply says nothing about the pulse. A capture at a NON-ZERO loop phase is
+  # what would let this row see it, and none exists -- filed in BLOCKED.md.
   "title_plate:$CAPS/live-title-press-a.png:plate"
   # A BANDED row -- the capture is 1279x120, not a full frame, and the harness
   # could not compare one until now. That was the only reason this capture sat