agents: the splash does not animate, and three instruments could not see it

A human on a GPU at ~140 fps: "the logos just switch, there is no animation at
all." Measured from a real boot with --film at 0.05 s, then per-frame change:

  splash moves        1.30 s of 7.95 s = 16.4 %
  publisher splash    0.30 s of motion, then 3.20 s FROZEN
  developer splash    0.35 s + 0.25 s, then 2.40 s FROZEN
  distinct luma states in 7.95 s   26

A 45-unit build-in cannot be drawn in 26 states, and a fade does not hold one
picture for 3.20 s. The frame counter says 24.8 fps achieved; both are true --
the port is DRAWING 25 times a second and CHANGING almost never.

🔴 Why every check passed, which matters more than the bug:

  frozen sweep     drives the clock BY HAND -- proves the renderer can draw
                   pose N, never that the poses are drawn in sequence
  settled compare  0.01 % against the capture -- a screen frozen 84 % of the
                   time matches a settled reference PERFECTLY, that is what
                   frozen means
  achieved fps     counts frames DRAWN -- the same pixels 25x/s scores
                   identically to animating

Every one measured throughput or a pose. None measured CHANGE. Same shape as
InputEventAction bypassing the input map: the instrument sat below the thing
that was broken, so the break could not appear in it.

tools/motion-census closes the class. It measures change and nothing else, and
its --selftest asserts it separates a fade (97.4 % moving) from a switch (2.6 %)
from a frozen film (0.0 %) -- a detector that cannot tell those apart would
report the same green line on all three.

Both briefs: this is the SOLE focus. The port reproduces before changing
anything and gates every fix on a film rather than a still. The decoder maps the
whole pipeline end to end -- disc bytes, the game's per-frame update (does it
interpolate between keyframes or hold?), what is submitted per frame, and what
Canary does to it before a capture records it -- delivered as a SERIES, not a
settled value.

The port should also record the refutation against itself: H2 reads ANSWERED on
the strength of the frozen sweep. The mechanism half stands, the blur is a baked
companion texture. The behaviour half does not.

docs/agents/decoder-loop.md

@@ -1,7 +1,58 @@
 You are the **Decoder**. Answer the open questions the Godot menu port is
 blocked on, one at a time.
 
-## 🔴 CURRENT FOCUS, set by the human 2026-09-01: THE LOGO SPLASHES, EXACTLY
+## 🔴🔴 SOLE FOCUS, set by the human 2026-09-02: THE WHOLE GRAPHICS PIPELINE
+
+**Read [`PLAYTEST-2026-09-02.md`](PLAYTEST-2026-09-02.md) first. Work nothing
+else until this is answered.**
+
+A human on real hardware: *"the logos just switch, there is no animation."*
+Measured from a real boot — **the splash moves 1.30 s of 7.95 s (16.4 %)**, the
+publisher logo frozen **3.20 s**, and the whole thing takes **26 distinct luma
+states**. The port draws the right quads in the right places and never moves
+them.
+
+Your half is not the port's bug. It is that **nobody can say what the game does
+between keyframes**, so nobody can say what the port should be doing.
+
+### The deliverable, in the human's words
+
+> *"Get the whole graphics pipeline, from the xex/pe + the disc files to the
+> final screen displayed. Take Xenia Canary processing into account too."*
+
+One continuous account, each stage carrying its evidence and its `⟨instrument⟩`:
+
+```
+disc bytes → RATC/T8aD decode → what the GAME CODE does per frame
+           → the draw calls it submits → Canary's own processing
+           → the presented frame
+```
+
+Three questions that are load-bearing and none answerable from a file alone:
+
+1. **The per-frame update.** Which function advances a UI group's clock, in what
+   units, and **what does it do BETWEEN keyframes** — interpolate, or hold to the
+   next key? That single answer decides whether the port should lerp at all. It
+   is in the image. Find it.
+2. **What is submitted per frame during the splash** — the draw list frame by
+   frame, not one settled frame. If alpha changes it changes *somewhere*
+   observable: a vertex colour, a PS constant, a blend factor, a texture swap.
+   **Name which, and give the per-frame series.**
+3. **What Canary does to it** — present cadence, and any resolve, scale or gamma
+   between the guest's draw and the pixels a capture records. A capture is
+   evidence about *Canary's output*; the gap between that and the guest's intent
+   has bitten this corpus before (`kernel_display_gamma_type`).
+
+⚠️ **Deliver a SERIES, not a settled value.** Follow
+[`TEMPORAL-VERIFICATION.md`](TEMPORAL-VERIFICATION.md): film it, align by
+content, report ordering and counts and durations. The port needs the alpha
+*trajectory*; a single frame cannot carry one.
+[`../../tools/motion-census`](../../tools/motion-census) measures change and
+nothing else — use it on your own captures too, and note that three of the
+port's instruments passed a frozen screen because each measured throughput or a
+pose rather than change.
+
+## Previous focus, 2026-09-01 (still live, but AFTER the above)
 
 A human played the port on real hardware and reported that the splashes are
 **close but not right** — the fade/blur is more pronounced in the game — and that