re: a .t32 element carries no blend/alpha mode -- undecodable, with reach

Answers the port's ask about ptframe1/ptframe2, whose residual is uniquely higher on
flat pixels than edges and signed one direction -- a body-intensity difference.

Prior work covers .prm primitives and a refuted T8aD +0x04 bit; neither covers a
.t32 element. All 15 words of the 60-byte declaration entry are read: 3 are the
name, 8 constant, the rest kind, focus index, position and pivot. The frames are
kind 0, identical to every other plain sprite.

One candidate found and refuted by myself: T8aD +0x08 is the only word where both
frames agree uniquely on that screen, at 0x8050 -- but 38 sprites carry it
disc-wide, only 8 named frame, and the high byte tracks the archive. It is an
atlas/format word, not a mode.

Also records a false positive of my own test: +0x00 and +0x08 first read as
'separating the frames' because those words are the name string.

So any blend the port picks is authored. Reach: not looked at the executable's draw
path, where a mode selected in code rather than data would live.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/structures/t32-blend-mode-not-on-disc.md

@@ -0,0 +1,59 @@
+# A textured element carries no blend/alpha mode — ❔ undecodable, with reach
+
+**Answers `sylpheed-port`'s ask**: what blend/alpha mode do `ptframe1` and
+`ptframe2` use on the main menu? They measure those two elements as the only ones
+whose residual is **higher on flat pixels than on edges** (25.41/16.54 against
+19.85/9.82), signed one direction, `ptframe1` rendering at 88.4 against the
+capture's 129.1 with 0.1 % of pixels render-brighter — a body-intensity difference,
+not a geometric one.
+
+## The answer: it is not on the disc, and the port is authoring
+
+⚠️ Prior work covers **`.prm` primitives**
+([`ui-prm-blend-mode.md`](ui-prm-blend-mode.md), ❔ undecodable with reach) and a
+**refuted** `T8aD +0x04` bit. Neither covers a `.t32` element, which is what was
+asked. This does.
+
+### Reach 1 — the declaration entry (60 bytes, all 15 words read)
+
+| words | what they are |
+|---|---|
+| `+0x00`–`+0x0B` | the **name** string (`ptfr`, `ame1`, `.t32`) |
+| `+0x0C`–`+0x1F` | **constant 0** across every element on the screen |
+| `+0x20`, `+0x24` | constant `FFFFFFFF` |
+| `+0x28` | **kind** — 0 plain, `0x10` primitive, `0x3002` button |
+| `+0x2C` | **focus/nav index** — `−1` for non-buttons, 1…5 for the five buttons |
+| `+0x30`, `+0x34` | position / pivot |
+| `+0x38` | constant 0 |
+
+🔴 **The two frames are `kind 0` — identical to `ptbase`, `pteff05`, `pteff10`,
+`pteff12` and `ptmsg`.** Nothing in the declaration distinguishes them.
+
+⚠️ A first pass reported `+0x00` and `+0x08` as "separating the frames". **False
+positive of my own test**: those words are the name, and the frames share a prefix
+and a suffix no other element has.
+
+### Reach 2 — the sprite's own `T8aD` header, and a candidate I refuted
+
+`+0x08` is the one word where both frames agree on a value no other menu sprite
+has: **`0x8050`**. Tested disc-wide before offering it:
+
+* **38 sprites carry `0x8050`, only 8 named `*frame*`** — not frame-specific;
+* the **high byte tracks the archive** — `0x80xx` in `GP_TITLE`, `0xb1xx` in
+  `GP_OPTIONS`, `0xd8xx` in `GP_GAMEOVER`, `0xf0xx` in `GP_DIALOG`.
+
+❌ So `+0x08` is an atlas/format word, **not a mode**. The candidate is dead.
+
+## What this means for the port
+
+**Any blend the port picks for these elements is authored, not transcribed**, and
+must be labelled that way. ✅ Their refusal to brighten the frames until they match
+is the right call for the reason they gave: a blend invented on their side is
+indistinguishable from a decoded one in a month — and this page is the evidence
+that there is nothing to decode it *from*.
+
+⚠️ **Reach of the negative**: one screen's declaration table read exhaustively, the
+`T8aD` header's low words compared across every sprite on that screen and one
+candidate word censused disc-wide. **Not looked at**: the executable's draw path,
+which is where a mode selected in *code* rather than *data* would live. That is a
+route, and it is the one left.