re: the pivot mismatch cannot be the swoosh's cause -- refuting my own

candidate with the check I named

Last iteration I offered the pivot mismatch as a quantified candidate for
the swoosh rendering too thick, and said explicitly that whether it bites
depends on which pivot the compositor uses and that I had not checked. I
checked.

blit takes the drawn size from the TEXTURE and uses the pivot only as the
scale anchor, kf.x minus pivot times scale-minus-100 over 100. At scale
100 that term is zero. And every one of the seven swoosh elements --
ptlogo_back2, its glow and the five eff segments -- reports a single
scale of (100,100) across all its keyframes. So the mismatch, real as it
is in the data, cannot move or resize the swoosh in our render. Refuted,
under my own name.

It is not harmless everywhere, and I have said where it does bite:
ptlogo1 and ptlogo2 run 100, 101, 103, 112, 150 during the build-in, so
there the wrong pivot really does displace them -- during the animation
rather than at rest.

What that leaves is the blend, by elimination rather than by evidence.
Position and size are the texture's own and right, fade is
white-with-alpha, tint is white, the texture is blue-leaning rather than
pink. Seven overlapping sprites at 5 to 23 percent opacity stacked with
plain alpha-over saturate toward opaque white, which is what we draw and
would read as thicker beside the game's thin coloured stroke. Recorded as
the remaining candidate and explicitly not as a diagnosis -- no blend
mode has been identified in the data.

docs/re/REFUTED.md

@@ -35,6 +35,13 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "the title logo elements' wrong pivots (off by up to 59 px, authored against the
+  other language's sprite) explain the swoosh rendering too thick" → **mine, and
+  refuted.** `blit` sizes from the texture and applies the pivot only as
+  `pivot·(scale−100)/100`; all seven swoosh elements are scale `(100,100)` at every
+  keyframe, so the term is zero. The mismatch is real but inert here — it would
+  bite `ptlogo1`/`ptlogo2`, which scale to 150 during the build-in.
+  [`ui-title-build-map.md`](ui-title-build-map.md)
 * "the title screen loops at ≈ 2.2 s" → **mine, and doubly wrong.** The title
   *art* is near-static (wordmark sd 0.06); the 2.3 s pulse is the
   **`PRESS Ⓐ BUTTON` plate**, which is a *different build* (2, not 4). Localised

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

@@ -464,11 +464,35 @@ Note it cuts **both ways**: the Japanese build's `ptlogo1` is off by 40 px too.
 A 59 px offset on a 1118 px sprite is the right order to produce "too thick and
 extending too far right", which is what the crop shows.
 
-❔ **Whether this is the cause depends on which pivot our compositor uses** — the
-declared one or the texture's own. That was **not** checked, so this is a
-quantified candidate, not a diagnosis. And it does not explain the **colour** at
-all: nothing in the fade, tint or texture is pink, so the magenta edge must come
-out of blending.
+### 🔴 …and that candidate is refuted
+
+Checked, as promised. `ui_layout`'s `blit` takes the drawn size from the
+**texture** (`img.width`/`img.height`), and uses the pivot only for the
+scale anchor:
+
+```rust
+let ox = kf.x - (pivot_x as i32 * (sx_pct as i32 - 100)) / 100;
+```
+
+At `sx_pct == 100` that term is **zero**. And **every one of the seven swoosh
+elements is scale `(100,100)` at every keyframe** — `ptlogo_back2`,
+`ptlogo_back2eff` and `ptlogo_back2eff1…5` all report a single scale. So the
+pivot mismatch, real as it is in the data, **cannot** move or resize the swoosh in
+our render.
+
+⚠️ It is not harmless everywhere: `ptlogo1`/`ptlogo2` run scales
+`100 → 101 → 103 → 112 → 150` during the build-in, so there the wrong pivot *does*
+displace them — during the animation, not at rest.
+
+### 🟡 So the swoosh defect is a BLEND problem, by elimination
+
+Position and size are the texture's own and are right; fade is white-with-alpha;
+tint is white; the texture is blue-leaning, not pink. What remains is how the
+seven overlapping sprites are combined — `ptlogo_back2` is only **5.4 % opaque**,
+its glow 10.3 %, the five `eff` segments 10–23 %, all white or warm. Stacked with
+plain alpha-over they saturate toward opaque white, which is what we draw and
+would read as "thicker" beside the game's thin coloured stroke. ❔ Not diagnosed —
+no blend mode has been identified in the data.
 
 ### 🔴 Refuted on the way