re: the swoosh is solved -- the game draws it as rotated quads and our

blit cannot

Ran the route I corrected last iteration, and it answered the question I
had classified as undecodable.

First the ninth candidate died: every vertex colour in the whole capture
is <alpha>FFFFFF, white RGB with only alpha varying. The game passes no
colour, so that hypothesis is refuted from the running game rather than
from the file.

Then the geometry gave it away. Draw 2 submits TWO PARALLELOGRAMS,
neither axis-aligned -- edges (0.54,-0.56) and (0.44,0.79), roughly 45
and 61 degrees, both extending to y=+/-1.81 in NDC, well off screen.
That is the diagonal Z stroke. And ui_layout::blit walks rows and columns
of an axis-aligned rectangle; it has no rotation at all. So we blit the
sprite upright where the game draws it skewed, which is exactly the
signature I measured: right on average at +1.83, right in position with
the correlation peaking at zero shift, wrong in structure at 0.70.

Nine candidates, and the answer was never going to be a field, because
the difference is not in the sprite -- it is in how the quad is built.

Two things left open and written as such. The decoded keyframe carries
fade, scale, tint, x, y and time and NO rotation, so where the rotation
comes from is not decoded. And the pink-versus-white reading I have been
carrying was a visual comparison of two differently-shaped renderings; it
should be re-checked after geometry rather than treated as a separate
defect.

docs/re/ui-title-build-map.md

@@ -555,7 +555,7 @@ Identical to within 0.001 over 17.5 s. **The band is settled by t = 4.0 s**, the
 capture handed to the port agent is sound, and the caveat is withdrawn. It also
 corroborates that the groups **hold**: nothing crosses that band in 22 s.
 
-## ❔ The swoosh: undecodable from the disc, with reach
+## The swoosh — SOLVED by draw capture (see below); the elimination trail kept
 
 Seven candidates eliminated, none confirmed:
 
@@ -595,3 +595,51 @@ So the route splits:
 
 Either way it is instrumentation of the running guest, not another field in the
 file.
+
+
+## ✅ SOLVED — the game draws the swoosh as ROTATED QUADS, which our blit cannot
+
+The route named in the previous section was run: `--ui_draw_capture_frames=3`,
+armed with F10 on the settled title.
+[`title-draw-capture-vertex-colours.log`](captures/title-builds/title-draw-capture-vertex-colours.log)
+is the capture, 22 draws over 3 frames.
+
+### 🔴 First, the vertex-colour hypothesis dies
+
+Every vertex colour in the entire capture is `<alpha>FFFFFF` — **white RGB**, only
+the alpha varying: `FFFFFFFF`, `C5FFFFFF`, `C3FFFFFF`, `B8FFFFFF`, `B6FFFFFF`,
+`31FFFFFF`, `1EFFFFFF`. The game passes no colour. That was the eighth candidate.
+
+### ✅ And the ninth is the answer — it is the GEOMETRY
+
+Draw 2 submits **two parallelograms, neither axis-aligned**:
+
+| quad | corners (NDC) | edge `v0→v1` | axis-aligned? |
+|---|---|---|---|
+| A | `(0.70,1.58) (1.24,1.02) (0.40,−1.57) (−0.14,−1.02)` | `(0.54, −0.56)` | **no** |
+| B | `(−1.29,1.02) (−0.85,1.81) (0.75,−1.02) (0.31,−1.81)` | `(0.44, 0.79)` | **no** |
+
+Both verified parallelograms (opposite edges equal to 0.01), both **rotated** —
+roughly 45° and 61° — and both extending to `y = ±1.81`, well beyond the screen.
+That is the diagonal `Z` stroke.
+
+**Our compositor cannot draw that.** `ui_layout::blit` walks destination rows and
+columns of an **axis-aligned rectangle** (`for row in 0..dh { for col in 0..dw`),
+sampling the source by a straight ratio. It has no rotation. So the swoosh is
+blitted upright where the game draws it skewed — which is exactly the observed
+signature: **right on average (+1.83), right in position (peak at (0,0)), wrong in
+structure (edge-corr 0.70)**, dark on one side of the true stroke and bright on
+the other.
+
+### ❔ And a real gap in the decoded format
+
+The keyframe carries `fade`, `scale_x`, `scale_y`, `tint`, `x`, `y`, `time`
+([`ui_layout.rs`](../../crates/sylpheed-formats/src/ui_layout.rs)) — **no
+rotation**. So where the game's rotation comes from is **not decoded**: either a
+field not yet identified, or the element is positioned by code rather than by its
+keyframes. That is the open question this leaves.
+
+⚠️ **The "pink versus white" reading is now suspect.** It was a visual comparison
+of two differently-*shaped* renderings. Whether any colour difference survives
+correct geometry is **untested**, and should be re-checked rather than carried
+forward as a separate defect.