re: downgrade -- the drift explains the 4.1% in sign, not magnitude

The port refuted the stronger half of the last claim and was right. I wrote that
the units/frame drift explained the publisher splash's 4.1% error against its
declared dwell. It explains the sign only.

Their test verified exactly here: the publisher/developer dwell ratio is 1.2143
declared, 1.2784 as the corpus's three cold boots measure it, and 1.3678 as this
container's drift predicts -- so the drift's direction is right and real evidence,
but its magnitude is about 2.4x too strong.

One refinement, because the means are being compared more finely than n=3
supports: the corpus's three boots individually give excesses of +0.89%, +8.24%
and +6.79%, a spread of 7.3 percentage points -- WIDER than the 5.30 pp gap under
test -- and boot 1's ratio (1.2251) is essentially the declared 1.2143. This run
sits 2.3 sigma above their mean: suggestive, not established.

Not closable without a frame log from the corpus's instrument, which was
screenshot timing and has none. An attempt to give this side an n of 3 failed on
tooling and is recorded: ARM=early loses its F10 about 40% of the time -- two of
five runs logged "ARMED EARLY" and produced no draw log at all, with nothing in
the session log distinguishing them.

Also fences the 33% drift against a misreading the port flagged: it is
PRESENTATION pacing and cannot reach keyframe_units_per_second = 60, which is the
game's logical rate, decoded under Q1, and which a renderer converts through at
its own frame rate.

And records a cross-check neither side went looking for: the batch counts are 1
and 2 on the publisher against 3 and 6 on the developer, and the port reports a
count restricted to SPRITE-BEARING elements reproduces that exactly from the
export -- so palogo_eff0, the layerless forced backdrop, is not in the batched
draw, confirmed from the file. Two instruments that disagreed about that element
in every previous iteration now agree on which one it is.

New tool splash_boundaries.py carries the corrected counting method.

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

docs/agents/CONTAINER-NOTES.md

@@ -236,3 +236,11 @@ scripted run that presses a button must watch `canary.stdout` and kill on growth
 8 s wait before arming means an `ARM=early` capture otherwise misses both splashes,
 which run at ~1.2–9.5 s of guest time) and `NOTAP=1` (no input at all — the movie
 tap fires on "the screen changed a lot", which is also true of a fading splash).
+
+### ⚠️ `ARM=early` loses its F10 about 40 % of the time
+
+Five `ui_draw_capture.sh ARM=early` runs on 2026-08-29: **two logged `ARMED EARLY`
+and produced no `xenia_re_ui_draws_NN.log` at all.** The keypress goes to the
+window and is silently lost — nothing in the session log distinguishes a run that
+armed from one that did not, so **check the log file exists before spending the
+run**, and treat a repeat measurement as needing more attempts than samples.