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/data/rotation-toplevel-census.txt

@@ -0,0 +1,32 @@
+CONTROL GP_TITLE build 4 (nested rotations only): 0 top-level rotated  (want 0)
+CONTROL GP_DIALOG build 0:                        2 top-level rotated  (want 2)
+          [4] pceff03.t32  r = [90, 30, 10, 3, 0, 0, 0]
+          [5] pceff04.t32  r = [90, 30, 10, 3, 0, 0, 0]
+
+top-level elements with a keyframe group, disc-wide: 15493
+  carrying a non-zero rotation:                      2152  (13.89 %)
+
+by archive:
+   1868  GP_READY_ROOM.pak
+     40  GP_DIALOG.pak
+     37  GP_MAIN_GAME_D2D.pak
+     37  GP_MAIN_GAME_E2D.pak
+     37  GP_MAIN_GAME_F2D.pak
+     37  GP_MAIN_GAME_I2D.pak
+     37  GP_MAIN_GAME_J2D.pak
+     37  GP_MAIN_GAME_S2D.pak
+     10  GP_GAMEOVER.pak
+      8  GP_DEBRIEFING_PILOTLOG.pak
+      4  GP_TITLE.pak
+
+most common rotated element names:
+    444  pbb_destroyer.t32
+    402  pbr_destroyer.t32
+    276  pbr_fighter.t32
+    174  pbb_fighter.t32
+    168  pbb_aircraft.t32
+     84  pb_warp_eff.t32
+     48  pbtab.t32
+     35  gbp012i.t32
+     32  pzeff02.t32
+     30  gbp001i.t32