re: a keyframe time is worth half a rendered frame, and the ramp is linear

Q1 of the menu port, measured against the running game rather than reasoned
about. The developer-logo splash is the cheap target: it is the first thing the
guest draws and its bundle declares short, unambiguous ramps.

Two results, both frame-exact and both emulator-speed-independent (frame numbers
are VdSwap counts, the guest's own frames):

  * the ramp is LINEAR. A declared 15-unit fade lands on round(255*k/15) for all
    seven of its samples with zero error, k stepping 2,4,6,8,10,12,14. No ease
    can reproduce a constant step of 34 at both ends.
  * the animation clock advances 2.000 time units per submitted frame, over six
    consecutive intervals with no residual, with 1 unit as the quantum
    underneath (one frame in the fade-out advances by 1).

The conversion to seconds is one step further and is flagged as such: 300 frames
took 10.87 s = 27.6 present-frames/second, which reads as a 30 Hz title at 92 %
under the emulator and gives 1 unit = 1/60 s -- the title build 4.2 s, the main
menu build 1.1 s. That reading is not proven, because the rate was measured
while the guest was still streaming from the ISO; the page names the one test
that would settle it and says what changes if it goes the other way.

Committed beside it: the raw draw capture and the per-frame quad CSV, so the
numbers can be re-derived without a disc or an emulator.

docs/re/METHOD.md

@@ -103,3 +103,17 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   out of noise.
 * **A probe that never performs the action will "prove" the action does not
   exist.**
+* **The container's Canary binary can be older than the Canary source tree, and
+  the failure mode is a hang, not an error.** After a merge into `sylpheed-re`
+  the prebuilt `xenia_canary` had no `log_ui_draws`, no `mem_watch`, no
+  `create_profile_if_none` — and an unknown cvar makes xenia open an SDL message
+  box before logging is up, which headless is an unexplained freeze. Check before
+  trusting a harness flag: `nm -C <binary> | grep cvars::<flag>`, and
+  `build-canary Release` if it is missing.
+* **A capture armed *at* a screen only ever sees the steady state.** Anything
+  about how a screen is built or animated has to be armed *before* it exists.
+  Re-arming every few seconds and keeping every log tiles the approach: each F10
+  opens a new numbered file and closes the previous one complete.
+* **Measure animation in submitted frames, not in seconds.** `VdSwap` counts are
+  the guest's own frames, so an emulator at 80 % of real time does not move them;
+  a stopwatch reading does, silently and by an unknown factor.