handoff: the blend is a bit on the disc, and their three asks

Delivered: T8aD +0x04 bit 0x02 selects additive, so the port derives the blend
instead of transcribing my table -- including for screens neither of us has
captured. With why I got it wrong first: the bit was already in REFUTED.md,
killed by a comparison of two renders made while our renderer had a stale
keyframe association, no leaf geometry and no rotation.

Their asks: pteff10 IS additive on the main menu, three sessions, every frame,
and my coverage table listing it uncovered there is corrected. The sweep ramp is
four leaf keyframes on the disc, with the oracle agreeing on sign and magnitude
and a second identification from the sub-128 alpha. And kind & 0x2 is not mine
to grant -- stated what the decode supports (0 violations in 15493 entries, and
it means the declaration marks the element focusable, not that the cursor can
reach it) and left the adoption to them.

ui-blend-mode-measured.md is superseded in its classification and keeps its
measurements, which are what the decode is fitted to.

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

docs/re/structures/ui-blend-mode-measured.md

@@ -1,5 +1,13 @@
 # The UI blend mode — ✅ **MEASURED**: the frames are drawn **ADDITIVE**
 
+> 🔴 **SUPERSEDED IN ITS CLASSIFICATION, 2026-08-31.** This page says the mode is
+> **measured** and that *"which field selects the mode is still unknown"*. The
+> field is now decoded — **`T8aD +0x04` bit `0x02`** —
+> [`ui-blend-mode-decoded.md`](ui-blend-mode-decoded.md). Every measurement below
+> stands and is the evidence that decode is fitted to; the instruction to read it
+> as per-element facts because no rule exists does not.
+
+
 **Status:** ✅ `CONFIRMED`, classification **measured** — nothing on the disc
 selects it, and this is what the running game tells the GPU, per draw, on two
 screens. 2026-08-31.