port: pre-register the plate composite test, and catch my own prediction being wrong

The Decoder's R2 note: alpha peaks at 80 of 255, so the composite difference is a
small signal either way and the expected magnitude should be set before the test.
Committed here before any capture exists.

Rendering the same pose at peak alpha under both composites: 25 015 px footprint,
mean |additive - alpha-over| 16.92 levels inside it, max 50, RMS over the whole
frame 3.746.

My first prediction was wrong and that is the useful part. The composites differ by
exactly alpha*bg, which with mean background 94.78 predicts 29.73 levels. Measured
16.92. The formula uses the keyframe alpha and ignores that the sprite carries its
own per-pixel alpha channel modulating it -- implied mean sprite alpha about
145/255. Caught only because the prediction was written down and disagreed with the
render.

The pre-registered test: additive is brighter than alpha-over at every footprint
pixel in one direction, so the discriminator is regional SIGN over 25 015 pixels,
not per-pixel magnitude. If the game is additive, rendering alpha-over must leave
the footprint about 17 levels darker than the capture relative to the surrounding
frame, and additive must leave no such regional bias. Neither bias refutes both and
points at the ramp or the pose instead.

Feasibility stated before asking for a run: as a whole-frame RMSE the difference is
3.746, below the title's own +/-5.56 capture-phase term, so verify-capture's
headline number could not settle this even at peak alpha. It is discriminable only
as a signed regional statistic.

docs/port/DECISIONS.md

@@ -16469,3 +16469,49 @@ stating because I did not have to assume which clock the record runs on.
 ⚠️ So the ask narrows to one number and gets a precise window: **a capture anywhere
 in t mod 120 ∈ [35, 50]**, where α holds at its peak of 80. Everything else about
 the plate is now settled on my side.
+
+### Pre-registered: what the plate capture must show, committed before it exists
+
+The Decoder's R2 note, and it is the right one to raise: α peaks at **80 of 255**,
+so an additive overlay at 31 % is a small signal and *"whatever residual you
+measure will be small in absolute terms whether or not the blend is right."*
+**So the expected magnitude goes in git before the capture does.**
+
+Rendering the same pose at peak α under both composites:
+
+| | value |
+|---|---|
+| highlight footprint at peak α | **25 015 px** (2.90 % of frame) |
+| mean \|additive − alpha-over\| **inside** it | **16.92 levels** |
+| max | 50 levels |
+| RMS over the **whole frame** | **3.746** |
+
+🔴 **And my first prediction was wrong, which is the useful part.** The two
+composites differ by exactly `α·bg`, and with mean background 94.78 that predicts
+**29.73** levels. Measured: **16.92**. The formula uses the *keyframe* α and
+ignores that **the sprite carries its own per-pixel alpha channel**, which
+modulates it — implied mean sprite α ≈ 145/255. Caught because I wrote the
+prediction down and it disagreed with the render, which is the whole point of
+writing it down.
+
+**The pre-registered test.** Additive is brighter than alpha-over at *every*
+footprint pixel, in one direction. So the discriminator is **regional sign over
+25 015 pixels, not per-pixel magnitude** — which matters because the port already
+carries global tone offsets of order 8.5 levels, and a per-pixel magnitude test
+would be swamped by them while a signed regional one is not.
+
+> **If the game composites this additively, then rendering it alpha-over must leave
+> the footprint systematically ≈17 levels DARKER than the capture relative to the
+> surrounding frame, and rendering it additive must leave no such regional bias.
+> A capture that shows neither bias refutes both, and points at the ramp or the
+> pose rather than the blend.**
+
+⚠️ **Feasibility, stated before asking anyone to spend a run:** 16.92 mean levels
+across 2.9 % of the frame against ~8.5-level systematic offsets is discriminable
+**only** as a signed regional statistic. As a whole-frame RMSE it is **3.746** —
+below the title's own ±5.56 capture-phase term, so `verify-capture`'s headline
+number could not settle this even at peak α.
+
+⚠️ Their gate `wait_plate_pulse.py` fires on a green-glyph count in [500, 2500] and
+has logged 740 and 1004, so the window may come free or may sit outside [35, 50]
+entirely. Their caveat, carried across rather than assumed away.