re: a candidate blend flag -- T8aD header +0x04, bit 0x02

Continuing the swoosh. Last iteration ended with "the next step is
finding where a blend mode would be encoded, and I do not know the format
carries one". It does carry a candidate.

The kind field is not it -- the swoosh sprites are kind 0x0, the same as
ordinary ones. But the T8aD header word at +0x04 splits the title's
sprites exactly along effect versus normal: pteff01, pteff03a,
ptlogo_back2eff1..5 and both ptlogoall_eff are 0x8832, while ptlogo1,
ptlogo2, ptlogo_tm, ptbase2, ptlogo_back2 and ptcopyright are 0x8830.
One bit, 0x02.

Disc-wide it behaves like a real flag rather than an artefact: 19216
sprites, 18 distinct values, bit 0x02 set in 27.1 percent, and it toggles
against otherwise identical words -- 0x8830 against 0x8832, 0x0830
against 0x0832, 0x0810 against 0x0812, 0x0030 against 0x0032.

Marked as correlation and not decode, because nothing here shows the bit
MEANS additive. The one thing that makes it more than a guess is
ptlogo_back2eff, which carries 0x8830 despite having eff in its name --
so the split is the field's and not my pattern-matching on names. The
test is to blend bit-0x02 sprites additively and re-correlate the title
against the plate-free capture.

METHOD gets the trap that cost the first attempt: searching for a
sprite's name and taking the next T8aD returns the SAME header for every
sprite, because the names all live together in the declaration table. It
failed its own control at once -- different sprites reporting identical
dimensions -- and the fix was to match on width and height instead of on
proximity.

docs/re/structures/ui-paint-order-key.md

@@ -448,3 +448,39 @@ against the capture over the pixels where they disagree. That needs a rebuild of
 same A/B this page already ran on the two screens that had oracles, and `EXTRAS`
 would be the first screen where the two orders can be judged against ground
 truth rather than declared indistinguishable.
+
+
+## 🟡 A second flag in the same header: `+0x04`, bit `0x02` (2026-08-28)
+
+This page reads the layer key at `+0x0A`. The word at **`+0x04`** is a different
+flag word, and on the title screen it splits the sprites exactly along
+**effect versus normal**:
+
+| `+0x04` | title sprites |
+|---|---|
+| **`0x8832`** | `pteff01`, `pteff03a`, `ptlogo_back2eff1…5`, `ptlogoall_eff`, `ptlogoall_eff2` |
+| **`0x8830`** | `ptlogo1`, `ptlogo2`, `ptlogo_tm`, `ptbase2`, `ptlogo_back2`, `ptcopyright`, `ptlogo_back2eff` |
+
+One bit apart: **`0x02`**.
+
+**Disc-wide** (19 216 `T8aD` sprites, top-level and `RATC`-nested): 18 distinct
+values, and bit `0x02` is set in **27.1 %**. It varies independently of the rest
+of the word — `0x8830`/`0x8832`, `0x0830`/`0x0832`, `0x0810`/`0x0812` and
+`0x0030`/`0x0032` all occur — so it is a genuine flag, not part of a larger
+enumeration.
+
+**Why it matters:** the title's swoosh renders opaque white where the game draws
+a thin coloured stroke, and every other candidate is eliminated — position and
+size come from the texture and match, `fade` is white-with-alpha, `tint` is white,
+and the texture itself is blue-leaning
+([`../ui-title-build-map.md`](../ui-title-build-map.md)). A per-sprite **blend
+mode** is what is left, and this is the only per-sprite field found that
+distinguishes the elements involved.
+
+⚠️ **This is a correlation, not a decode.** Nothing here shows the bit *means*
+additive. The test: blend bit-`0x02` sprites additively and re-correlate the title
+render against
+[`../captures/title-builds/live-title-build4-no-plate.png`](../captures/title-builds/live-title-build4-no-plate.png).
+Worth noting `ptlogo_back2eff` carries `0x8830` **despite** having `eff` in its
+name — so the split is the field's, not a naming pattern's, which is the one thing
+that makes it more than a guess.