re(ui): settle 8AX vs ptbase statically -- the game draws the full-res one

I had parked this as "needs a per-draw capture recording texture base
addresses". It did not. 8AX (1280x720) and ptbase (640x360 at 200%) are
the SAME artwork at two resolutions, which is exactly why comparing
either against a capture is inconclusive -- and why comparing their
DIFFERENCE is not. Compute 8AX - upscale(ptbase), the detail only 8AX
has, and ask whether the capture contains it.

Both candidates are first mapped into the capture's tone domain with the
measured gamma; without that the residual is dominated by the tone
difference and the test is blind.

  main menu  corr +0.0475   controls +0.0032 shift, -0.0075 flip   68% of ceiling
  title      corr +0.0634   controls +0.0095 shift, +0.0086 flip   68% of ceiling

Two independent screens, both at 68% of the theoretical ceiling
(sd of the 8AX-only detail over sd of the capture residual), 7-15x their
matched controls. The controls preserve spatial correlation and destroy
only alignment, so they are what "no signal" looks like.

So the recommendation changes: resolve the name and draw 8AX at 1:1.
Upscaling ptbase 2x is wrong, not merely softer. Still do not draw both --
an opaque layer over an identical one costs fill and hides later changes,
and ptbase's element is the one carrying the keyframes, so a consumer
needs its timing with 8AX's pixels.

Also recorded and withdrawn: a cruder pixel-pair test gave 0.00-0.72 for
upscales, 0.98 native and 1.01 for the capture -- apparently decisive.
Additive noise raises both terms of that ratio equally and drives any
value toward 1; fitting a noise term, both "native + noise" and "bilinear
+ noise" reproduce the observed numbers. The conclusion is right, that
test does not establish it, and it is in REFUTED because the number looks
conclusive and is not.

Not shown: whether ptbase is also drawn underneath. 8AX is ~86% opaque
and carries the same art, so it would hide it either way.

docs/port/HANDOFF.md

@@ -248,12 +248,21 @@ authored version can be deleted.
   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).
+  ✅ **SETTLED 2026-08-29 — the game draws the full-res `8AX`, so use it.**
+  Previously parked as "needs a per-draw capture"; it did not. The two carry the
+  same art at two resolutions, so what separates them is the detail `8AX` has
+  that an upscale cannot. Correlating the capture's departure-from-upscale
+  against the 8AX-only detail (both first mapped through the measured gamma):
+  main menu **+0.0475** vs controls +0.0032 / −0.0075, title **+0.0634** vs
+  +0.0095 / +0.0086 — **two screens, both 68 % of the theoretical ceiling, 7–15×
+  their matched controls**.
+  **So: resolve the name and draw `8AX` at 1:1.** Upscaling the 640×360 `ptbase`
+  2× is *wrong*, not merely softer. ⚠️ Do not draw **both** — an opaque
+  full-screen layer over an identical one costs fill and hides later changes; and
+  note `ptbase`'s element is the one carrying the keyframes, so you need its
+  timing with `8AX`'s pixels.
+  ⚠️ It does not show whether `ptbase` is *also* drawn underneath — `8AX` is
+  ~86 % opaque and would hide it either way.
   [`structures/ui-8ax-fullres-background.md`](../re/structures/ui-8ax-fullres-background.md)
 
 * ✅ **Paint order: your exposure is two element pairs, on one screen.** We use