re(ui): decode keyframe +12 as screen-plane rotation in degrees

The rotated quads on the title screen come from the keyframe block after
all. The earlier negative -- "every GP_TITLE build 4 element has all three
angle words at zero" -- read the right bytes over too small a region: it
walked the top-level declaration table, and the rotated elements are the
nested leaf records ptloop01.rat / ptloop02.rat.

Confirmed against the framebuffer rather than against our own renderer.
The two records declare +12 = 30 and -45; the GPU capture submits their
quads at +30.26 and -45.28 degrees -- magnitude and sign, two different
values. Corroborated by shape in GP_BUNK 117ca14f, where +12 ramps
0 -> 360 with position, scale and alpha constant: a spin in place.

Identifying which draw it was needed edge lengths, not bounding boxes:
400x1076 and 400x1444 against pteff03/pteff03a 399x180 at the elements'
two different declared scales, 600% (1080) and 800% (1440). The same test
names three known-positives in the capture (ptlogo1, ptcopyright,
ptbtn00), so it passes its own control.

Keyframe gains rotation_deg plus unknown_4/unknown_8, carried rather than
dropped. NOT rendered -- ui_layout::blit is axis-aligned only, so the
reference renderer and the port will both draw these upright until a
rotating blit exists.

The census tool ships with the trap that broke its first version: nested
RATC blobs are not 4-byte aligned, so an aligned scan found 0/3 of its
own control blocks and missed 16 341 blocks. Disc-wide +12 is non-zero in
14.50 % of 83 862 blocks.

sylpheed-formats tests, SYLPHEED_DISC set: 131 passed, 0 failed across the
6 suites finished at commit time; the run had not yet completed.

docs/re/METHOD.md

@@ -317,3 +317,30 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   beyond, the swoosh is a 234-pixel band. Five iterations of analysis pointed at
   the wrong element on the strength of it. Converting the coordinates takes one
   line and should come first.
+* **A census over a bundle's top-level table is not a census over the bundle.**
+  The keyframe rotation field read "always zero on this screen" for several
+  iterations because every scan walked `GP_TITLE` build 4's **declaration
+  table**, and the rotated elements are **nested leaf records** reached through
+  an `opt ` link. The bytes were right; the *reach* was wrong, and a negative
+  stated without its reach reads like a fact about the disc. Say which region a
+  negative covers, and check whether the thing you are looking for lives outside
+  it.
+* **Do not assume 4-byte alignment when scanning raw bundle bytes.** A nested
+  `RATC` blob starts wherever the parent's chunk stream leaves it — `ptloop01.rat`
+  sits at `0xbb5966` — so its 40-byte keyframe blocks are odd-aligned. A scanner
+  that filtered candidates on `%4 == 0` found **0/3** of its own control blocks
+  and under-counted the corpus by **16 341** blocks, all of them nested. It cost
+  nothing to catch, because the control was in the script.
+* **`pkill -f <pattern>` matches the shell running it.** `pkill -f kfscan.py`
+  from a `bash -c` whose command line contains `kfscan.py` kills its own shell:
+  the tool call returns exit 143/144 and the edit that was queued behind it never
+  runs. The same trap makes `pgrep -f` self-report — a "still running? yes" that
+  was the shell seeing itself, on a job that had already finished. Use
+  `pgrep -x`, or match on a path the current command line does not contain.
+  (This is the second `ps`/`pgrep` entry in this file; the first is about
+  `ps -ef` dumping the loop prompt.)
+* **Grep a legend and you count the legend.** A sweep for elements with a
+  rotation reported "1 element" in every build on the disc — the header line
+  `a=alpha r=rot°` matched the ` r=` pattern. A uniform count across
+  heterogeneous inputs is the tell. Make the pattern require the *value*
+  (` r=-?[0-9]+`), and sanity-check that a known-negative build reports zero.