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.

authored/rendering.json

@@ -154,7 +154,11 @@
    "pteff23",
    "ptloop01",
    "ptloop02"
-  ]
+  ],
+  "press_start": [
+   "ptbtn00f"
+  ],
+  "title": []
  },
  "additive_elements_why": [
   "TRANSCRIBED, not authored, and the distinction is the whole entry. The port",