re(ui): a full-screen element is dropped on three port screens -- do not "fix" it

Audited what `screen render` silently omits on the port's five screens,
since an element the game draws but we skip is the one defect class the
port agent has actually hit. Everything is accounted for -- kind & 0x4
ghost instances, .prm primitives, loop* animations -- except pteff04.t32
on the title and pteff05.t32 on both menus. Those are kind 0x0, one
keyframe, rest a=255, pivot (640,360): full-screen and opaque.

Cause: the element declares pteff05.t32, but the T8aD behind its `opt `
link is registered under the name 8AX, so build.sprites.get() misses and
compose hits a silent continue. Bytes at 0x0e2035 of GP_TITLE entry 5:

  opt  ... 70 74 65 66 66 30 35 2e 74 33 32 00  38 41 58  54 38 61 44
           p  t  e  f  f  0  5  .  t  3  2  \0  8  A  X   T  8  a  D

8AX is 1280x720 and present in all six title-family bundles; it is a
sprite in builds 4/5/6 and never an element.

It does not currently show, and that is the useful half. ptbase.t32 is
640x360 drawn at 200% and carries THE SAME ARTWORK: its 2x upscale
differs from 8AX by mean abs diff 2.05 (max 80), and our rendered
background is pixel-identical to 8AX in every patch sampled. So resolving
the name and drawing it in addition would double-draw an opaque
full-screen layer -- invisible as a doubling, which is worse than a
visible bug. Written into HANDOFF as a do-not-do.

The free win, offered and not taken: use 8AX at 1:1 and drop ptbase
instead of upscaling a half-res copy. That is a rendering choice and
ptbase's element carries the keyframes, so it is the port's call.

Not established: which of the two the game actually draws. Both carry the
same art, so pixels cannot separate them; it needs a per-draw capture
recording texture base addresses, since the two differ in size.

docs/port/HANDOFF.md

@@ -219,6 +219,27 @@ authored version can be deleted.
   ⚠️ An earlier version of this bullet said "the title screen loops at ≈ 2.2 s"
   and attributed it to `ptloop01/02`. Both halves were wrong: it is the **plate**,
   and it is a different build.
+* 🟡 **`screen render` silently drops one full-screen element per screen — and
+  you must NOT simply draw it.** Auditing what the composer omits on your five
+  screens: everything is accounted for (`kind & 0x4` ghost instances, `.prm`
+  primitives, `loop*` animations) except **`pteff04.t32`** on the title and
+  **`pteff05.t32`** on both menus. Those are `kind 0x0`, one keyframe, rest
+  `a = 255`, pivot `(640,360)` — full-screen and opaque.
+  **Cause:** the element declares `pteff05.t32`, but the `T8aD` behind its `opt `
+  link is registered under the name **`8AX`**, so the sprite lookup misses and a
+  silent `continue` drops it.
+  ✅ **It does not currently show,** because `ptbase.t32` (640×360, drawn at
+  200 %) is *the same artwork at half resolution* — its 2× upscale differs from
+  `8AX` by mean 2.05, and our background is pixel-identical to `8AX` in every
+  patch sampled.
+  ⚠️ **So resolving the name and drawing it as well would double-draw an opaque
+  full-screen layer** — invisible as a doubling, which is worse. If you want the
+  sharper background, use `8AX` at 1:1 and *drop* `ptbase`; don't add it.
+  ❔ Which of the two the game actually draws is not established — both carry the
+  same art, and separating them needs a per-draw capture recording texture base
+  addresses (the two differ in size).
+  [`structures/ui-8ax-fullres-background.md`](../re/structures/ui-8ax-fullres-background.md)
+
 * **Menu order is geometric.** Buttons sorted top-to-bottom by resting Y. This is
   ✅ correct for a vertical menu and is **not** a decoded neighbour graph — the
   disc's real navigation structure is unknown, and `opt ` is *not* a focus link