port: their "do not draw all five flashes" flag, checked -- the port already staggers them

The Decoder caught the title's build-in on the console and found ptlogo_back2eff3
never drawn -- not a miss, but phase: a flash's peak is 2 keyframe units, 0.85 of
a presented frame at that pacing, so the console shows a SUBSET on any given
play. The warning was that drawing all five would read heavier than the real
thing.

Checked rather than reasoned about. Sweeping the build-in with --no-hold, the
port draws them sequentially -- eff1 at t54-56, eff2 at 58-60, eff3 at 60-62,
eff4 at 62-64, eff5 at 64-68 -- never more than two at once, and those only where
their declared windows abut. That is the stagger the disc declares. The pile-up
was the rest() bug and it is fixed.

SO THE DIFFERENCE FROM THE CONSOLE IS PRESENTATION RATE, NOT CONTENT. At 60 fps
each 2-unit flash gets ~2 frames; at the console's pacing it gets 0.85, so some
are skipped. A frame-by-frame comparison of the build-in against a console
capture will show flashes the console missed -- a fact to know rather than a bug
to fix. The settled comparison verify-capture makes is unaffected: at t=198 none
of the five is drawn.

Also recorded: my top-level restriction on the settle window was verified by them
rather than merely accepted ([160,236] width 76 against [269,540] width 271 with
the leaves in, which is an instant after every top-level element has exited); the
120-unit loop is confirmed from the guest's own vertex colour alpha, observed
range 0..80 against a decoded peak of 80, with the decoded ramp fitting at RMS
13.16 against 38.18 reversed; and a trap for any future draw-stream tooling here
-- a 2D draw's identity is its vertex geometry, not its bound texture, because
these sprites sample large shared pages.

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

docs/port/DECISIONS.md

@@ -4497,3 +4497,58 @@ a 127–255 range looks entirely plausible, and nothing reports it.**
 ✅ And a free second instance of the loop-length decode from a pak neither of us
 was looking at: `py_ranking_btn01f`'s ramp ends at **t=90 inside a declared 120**
 — 30 units of hold, the same shape as the plate's 105-in-120.
+
+## Their "do not draw all five flashes" flag — checked, and it does not apply here
+
+The Decoder armed a draw capture before the title exists and caught the build-in
+on the console: `ptlogo_back2eff1` in frames 130–131, `eff2` at 133, `eff4` at
+133–135 — and **`eff3` never drawn at all.** Not a miss: a flash's peak is 2
+keyframe units, which at that run's pacing is **0.85 of a presented frame**, so
+which flashes get sampled is a matter of phase. The console shows a *subset* on
+any given play, and the warning was that drawing all five would read heavier than
+the real thing.
+
+**Checked rather than reasoned about.** Sweeping the port's build-in with
+`--no-hold`:
+
+| t | flashes drawn |
+|---|---|
+| 54, 56 | `eff1` |
+| 58 | `eff2` |
+| 60 | `eff2`, `eff3` |
+| 62 | `eff3`, `eff4` |
+| 64 | `eff4`, `eff5` |
+| 66, 68 | `eff5` |
+
+**The port draws them sequentially, never more than two at once**, and the two
+only overlap where their declared windows abut. That is the stagger the disc
+declares, not a pile-up — the pile-up was the `rest()` bug, and it is fixed.
+
+⚠️ **So the difference from the console is presentation rate, not content.** At
+60 fps each 2-unit flash gets ~2 frames; at the console's pacing it gets 0.85, so
+some are skipped. **A frame-by-frame comparison of the build-in against a console
+capture will therefore show flashes the console missed, and that is a fact to
+know rather than a bug to fix.** It is also why the settled-frame comparison —
+the one `verify-capture` makes — is unaffected: at t=198 none of the five is
+drawn.
+
+### Three things of theirs worth recording
+
+✅ **My top-level restriction was verified, not merely accepted**: top-level
+`[160, 236]` width 76, versus `[269, 540]` width 271 with the `ptloop` leaves
+included — an instant *after every top-level element has exited*. Worth having on
+their page, because the rule as described permits the wrong reading.
+
+✅ **The 120-unit loop is confirmed from the guest's own vertex data**, not
+inferred from pixels: the glow quad's per-vertex colour alpha *is* the element's
+fade alpha, giving an observed range of **0…80 against a decoded peak of 80**,
+exact and unfitted, over 20 cycle starts. Fitting the decoded ramp gives RMS
+13.16 alpha levels against **38.18 for the same ramp reversed** — if the shape
+carried no information those would be equal.
+
+📌 **A trap noted for whenever this port grows draw-stream tooling:** a 2D draw's
+identity is its **vertex geometry, not its bound texture**, because these sprites
+sample large shared pages. Matching on texture dimensions told them first that no
+flash is ever drawn, then that `ptbase2` and `pteff04` are drawn in frames 75–105
+— which are the intro movie, whose YUV planes are 640×360 targeting 1280×720.
+Two errors, opposite directions, one pass, neither loud.