port: P3 -- the boot title gets its PRESS (A) plate, and two of the RE agent's numbers do not agree

ScreenView now draws two builds at once, which it never had to before. It is a
second ScreenView in the same SubViewport rather than a subordinate screen
inside one: each build has its own timeline, its own textures and its own hold,
which is the entire content of the finding, and Node2D siblings already paint in
tree order. `paint_order` still means what it meant -- an ordering WITHIN a
build.

The delay is authored in flow.json on the BOOT STEP, not on the `title` screen.
What was measured is the boot title; whether the plate is there when the title
is reached again -- (B) from the menu, or after the attract movie -- is not, and
hanging it on the screen would quietly claim that it is.

REFUTATION, and it is the substance of this commit: the RE agent's authoring
instruction does not reproduce the RE agent's own measurement, and the gap is
3.97 s. The instruction is "when build 4 has settled, wait 2.13 s, composite
build 2". But build 2 has a group and this port plays groups -- ptbtn00 is alpha
0x00 at t=214, still 0x00 at t=236 while it slides 10 px up, and 0xff only at
t=238, which is 3.967 s at 60 units/s. So the plate is first VISIBLE at
settle+6.10 s, while what was measured -- the glyph counter leaving 154 -- is
visibility at settle+2.13 s. Both groups starting together puts it 0.38 s BEFORE
settle; build 2 starting at settle puts it at settle+3.97 s; landing on the
measurement needs build 2's group to start 2.51 s after build 4's, which is not
a landmark of anything.

The measurement is untouched -- it is an observation of the running game and I
have no standing to doubt it. What is refuted is the step that turns it into an
authoring rule. So the port ships the instruction, prints the discrepancy on
every boot, and files the row. Same call as the BGM sub-waves: a port that
quietly picks the number that looks right destroys the evidence, because a
corrected boot looks exactly like a correct one.

Also refuted, and it was mine: BLOCKED.md has said since P2 that "no element's
alpha reverses direction anywhere in this export, so nothing pulses". ptbtn00
reverses -- 0x00 -> 0xff -> 0x00 -- and it was in the export the whole time. The
claim had been checked against the screens P2 happened to be animating. The port
still draws no pulse, because no reading of this group yields the measured
2.24 s: the whole group is 4.47 s and from its first keyframe 0.90 s.

Gate: `--boot --capture=` writes one frame of the composited end state, instead
of the 600-PNG filmstrip that was previously the only boot artifact.
`--screen=title --overlay=press_start` raises the same composite in two seconds
for anyone who does not want to sit through 137 s of Theora.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WM5XL4HfrHuxz8RiMWdCMC

authored/flow.json

@@ -29,6 +29,15 @@
     },
     {
       "screen": "title",
+      "overlay": {
+        "screen": "press_start",
+        "after_settle_seconds": 2.13,
+        "why": "MEASURED, 2026-08-29, docs/re/title-plate-delay-measured.md on branch auto/no-disc-and-menu-captures at fb536df (NOT yet on main when this was written). The boot title shows build 4 ALONE, and the `PRESS (A) BUTTON` plate -- build 2 -- is composited over it 2.13 s later. Two independent boots of the real game agree to 6 ms. This is the ONE case in the port where two builds are drawn at once.",
+        "measured_from_why": "The 2.13 s is timed from the frame build 4's own build-in animation FINISHES, not from the frame the title art first appears. That distinction is the finding, not a detail: measured the other way the two runs differ by 0.48 s, because the build-in itself ran 1.64 s and 2.13 s and the emulator's frame pacing during an animation is not the game's clock. A number taken from the wrong instant here looks exactly like a measurement.",
+        "not_a_fade_in_why": "The alternative -- that the plate was there all along, pulsing too dim to see -- was tested and refuted on two observables. The plate's declared alpha never exceeds 0x50, so a thresholded glyph counter could in principle miss a dim phase; it does not. The count sits at EXACTLY 154 with zero variation for 1.99 s / 2.13 s and then swings 714-1520, and the surface mean is flat to +/-0.03 across the plateau. A pulsing overlay moves the frame mean.",
+        "scope_why": "Attached to the BOOT STEP, not to the `title` screen, and that is deliberate. What was measured is the boot title. Whether the title shows the plate when it is REACHED AGAIN -- by (B) from the main menu, or after the attract movie -- is not measured, and putting the overlay on the screen would quietly claim it is. See docs/port/BLOCKED.md.",
+        "no_pulse_why": "The port draws the plate arriving and then HOLDING VISIBLE. It does not pulse it. The plate's own group encodes exactly one cycle -- alpha 0x00 at t=214, 0xff at t=238-244, 0x00 on the final untimed keyframe -- and the port holds at the settle (t=238, alpha 0xff) as it does on every other screen. The running game was measured pulsing continuously at peak intervals averaging 2.24 s, and NO reading of this group produces 2.24 s: looping the whole group gives 268 units = 4.47 s, looping from the first keyframe gives 54 units = 0.90 s. So repeating the group here would be inventing a period, and the port does not. Filed in BLOCKED.md."
+      },
       "why": "HANDOFF Q2/Q6: the boot reaches the title after the intro movie. This is the LAST step, and a last step is where the sequence stops rather than fading out -- a boot that ends by fading to black looks like a boot that crashed. P5 gave the title somewhere to go, but that is a HANDOVER and not another boot step: `--boot` still stops here, and `--boot --play` hands the same held title to the menu flow, where (A) opens TITLE_MENU. Kept as a stop rather than folded into `screens` because what the boot does is authored from a measured sequence, and what (A) does is a separate measurement."
     }
   ],