docs/re: the loading screen never boots, and no other build explains the order

Two routes closed, both cheaply.

The loading screen was the best discriminator reachable WITHOUT navigation — its
full-screen element is declared 7th of 10, so the two candidate orders would look
completely different. It does not appear during the boot at all: 23 captures
armed across an entire boot are all intro-movie frames, two full-screen quads
apiece. It belongs to a content load, which is behind the main menu, which is
behind the (A) that works half the time.

And a loophole this document had left open is shut: the title's sprites were
matched to build 4 BY SIZE, so the game might have been running some other build
whose table lists them in the captured order. Only two bundles in GP_TITLE.pak
contain all seven sprites, and neither is ascending in the captured order.

Recorded rather than glossed: one sub-order is genuinely ambiguous, because
ptlogo_back2eff and ptlogo_back2eff5 decode to the same 1133x280 and sit at
declaration 20 and 18, either side of ptlogo_back2 at 19. The UI quad carries a
k_8_8_8_8 colour attribute the hook does not log yet, and the two rest at
different fade alphas — logging it would name them apart.

docs/re/ui-title-paint-order-capture.md

@@ -313,3 +313,48 @@ So there is now a **reliable route to the main menu** — wait for the first tit
 after boot, tap Ⓐ once — which is what the second screen's capture needed, and it
 is written into `tools/re-capture/`. Why the attract title stops accepting input
 is still unexplained.
+
+## Two more routes closed (2026-08-19)
+
+### The loading screen does not appear during the boot
+
+`GP_TITLE`'s 10-element loading build is the best *unnavigated* discriminator on
+the disc: its full-screen element `pgloading_baseeff` (640×360 at 200 %) is
+declared **7th of 10**, behind the spinner and the "NOW LOADING" text, so which
+of the two orders the game uses would be plain to see.
+
+It never shows up. Arming a capture every ~6 s across an entire boot — 23
+captures, `tools/re-capture/loading_draw_capture.sh` — yields **zero** loading
+sprites: every capture is the intro movie compositing two full-screen quads per
+frame. The loading screen belongs to a *content* load (a mission, the hangar),
+which is behind the main menu, which is behind the Ⓐ that works half the time.
+
+### No other build's table produces the observed order either
+
+A loophole this document left open: the title's sprites were matched to build 4
+by size, so perhaps the game runs a *different* build whose table happens to
+list them in the captured order. Checked against every RATC bundle in
+`GP_TITLE.pak`:
+
+```
+entry 4  (a60fcb85) n=24  all 7 sprites present, ascending=False
+   ptbase2:9  ptlogo_back2eff:20  ptlogo_back2:19  ptlogo1:0
+   ptlogo_tm:7  ptlogo2:1  ptcopyright:21
+entry 7  (b483e6e6) n=30  all 7 sprites present, ascending=False
+```
+
+Only two bundles contain all seven, and **neither lists them in the captured
+order**. So the disagreement is not an artefact of picking the wrong build.
+
+### One sub-order is genuinely ambiguous, and how to fix it
+
+`ptlogo_back2eff` and `ptlogo_back2eff5` decode to the **same 1133×280**, so the
+capture cannot say which of them the first quad of that draw is — and they sit at
+declaration 20 and 18, on opposite sides of `ptlogo_back2` (19). The pair is the
+one place the observed order might still be locally ascending.
+
+It is resolvable: the UI quad's second vertex attribute is a `k_8_8_8_8` colour
+(`6@12` in the capture's attribute list), and the two elements rest at different
+fade alphas (`back2eff5` ends at α=192, `back2eff` at α=255). Logging that colour
+would name them apart — a small addition to the hook, and worth doing before any
+further ordering hypothesis rests on that pair.