re(ui): finish the top-level rotation census; record the JP-capture blocker

Two threads had converged on needing one capture this container cannot
take, so this iteration records that and finishes something reachable.

BLOCKED, written into MISSION.md rather than worked around: Q1's keyframe
time association and the rest() rule for plateau-less elements both now
hinge on a running capture of GP_TITLE build 7, the Japanese title. The
console language is not settable here -- user_language appears only as
DECLARE_int32 at four call sites with no DEFINE anywhere in the tree, and
it is absent from the registered cvars in xenia-canary.config.toml. There
is no flag to pass, and guessing one is specifically unsafe: run-canary's
own header records that xenia calls ShowSimpleMessageBox from
ParseLaunchArguments before logging starts, so a bad flag blocks forever
with an empty log. Rebuilding canary to add the cvar would be improvising
around the blocker; it needs a human decision. Neither question blocks
the five menu screens.

FINISHED: the disc-wide top-level rotation count, left running four
iterations ago as a shell loop over `screen info --geometry` that never
completed (it decodes every texture per build). Walking the placement
region directly takes seconds.

  top-level elements with a keyframe group   15 493
  carrying a non-zero rotation                2 152  (13.89 %)

Both controls pass: GP_TITLE build 4 reports 0 (its rotations are the
nested ptloop records) and GP_DIALOG build 0 reports the expected two.

The control earned its place -- the first version indexed the pak with a
`screen list` BUILD number and got 0 for a screen that has two, because
GP_DIALOG build 0 is entry 2. GP_TITLE maps 1:1, which is how the
assumption survived. METHOD line added.

Two free corroborations of the rotation decode. The rotated population is
dominated by tactical-map ship icons -- pbb_destroyer 444, pbr_destroyer
402, pbr_fighter 276 -- i.e. markers rotated to heading, the single
largest use of the field on the disc. And GP_TITLE entry 7's Japanese
wordmark pieces settle from ALTERNATING tilts:

  ptlogo3a  r = 0, -14, -4, -1, 0, ...
  ptlogo3b  r = 0, +14, +4, +1, 0, ...
  ptlogo3c  r = 0, -14, -4, -1, 0, ...

Same magnitudes, opposite signs, all decaying to upright. A misread field
does not produce that.

docs/re/METHOD.md

@@ -419,3 +419,10 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   diff was then all zeros, because `cmp` had read a half-written PNG. Compare
   only after the job signals done, or skip the newest file. A "difference" that
   vanishes on re-examination is usually a race, not a flake.
+* **A `screen list` BUILD index is not a pak ENTRY index.** `GP_TITLE` happens to
+  map 1:1 (16 builds, entries 0–15), which is how the assumption survived;
+  `GP_DIALOG` does not — its build 0 is **entry 2**. Indexing a pak directly with
+  a build number silently reads a different bundle and reports a confident wrong
+  answer: a census control asked for the two rotated elements of `GP_DIALOG`
+  build 0 and got zero, from a bundle that genuinely has none. `screen list`
+  prints the mapping; use it rather than assuming identity.