handoff: elements can carry two records; focus_link is a misnomer

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/port/HANDOFF.md

@@ -6394,3 +6394,31 @@ as a check value.
 ⚠️ Third time a label has been the error rather than the measurement, all mine:
 `0x3003`/`0x3002`, ptcopyright-as-plate for the clock conflict, and now
 ptcopyright-as-plate again in a page written *after* I had corrected it.
+
+## ⚠️ An element can carry TWO records — 9.5 % of the disc does (`2ea2712`)
+
+`docs/re/element-records-enumerated.md`. Worth a look if your exporter resolves a
+record by name.
+
+`cargo run -p sylpheed-formats --example element_records -- GP_TITLE ptbtn00`:
+
+```
+   leaf   ptbtn00.rat    loop 120  ptbtn00.t32  [1 keys, peak a255]
+   focus  ptbtn00f.rat   loop 120  ptbtn00f.t32 [8 keys, peak a80]
+```
+
+**1 467 of 15 493 elements (9.5 %), across 815 builds**, carry a second record via
+`focus_link`. Their keyframes are invisible to anything that looks a leaf up by
+name and stops — which is exactly how I got α80 wrong.
+
+🔴 **`focus_link` is a misnomer.** Our parser documents it as "the focused state
+of a button". On `GP_TITLE` it is also `pgloading_loop1 → loop3 → loop4` (a chain
+of three loop animations) and `ptloop01 → ptloop02` (the two sweeps). It links
+records; focus is one use, not the meaning. I have not renamed it — the behaviour
+is right where it is read — but if you branch on the name's implication anywhere,
+that is worth checking.
+
+🟡 It also gives a better candidate for why the two sweeps share one `indices=8`
+draw: they are **linked**, not merely on the same texture page. Testable on the
+`pgloading` chain; I have no loading-screen capture, so it is named rather than
+claimed.