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/port/HANDOFF.md

@@ -79,18 +79,24 @@ authored version can be deleted.
   `ptlogo_back2eff1…5`. 🟡 Those five are also the group with the **known
   unsolved paint-order tie-break** (key `0x8083`) — same screen, same elements —
   but a blend-order swap explains white-instead-of-pink poorly.
-  🟡 **A quantified cause for the GEOMETRY**: these elements' declared **pivots do
-  not match their own textures**. `ptlogo_back2`'s pivot `(500,117)` is exactly
-  half the **Japanese** sprite (1000×234), not its own English one
-  (1118×262) — off by **59 px**, the right order to make the swoosh too thick and
-  too far right. 24 of 109 title elements are off by > 8 px, concentrated on
-  `ptlogo*`, and it cuts both ways (the JP build's `ptlogo1` is off by 40).
-  ❔ Whether it *bites* depends on which pivot the compositor uses — **not
-  checked**.
+  🔴 **The pivot mismatch is NOT the cause — checked and refuted.** These elements'
+  declared pivots really do belong to the *other language's* sprite
+  (`ptlogo_back2`'s `(500,117)` is exactly half the Japanese 1000×234, not its own
+  English 1118×262; 24 of 109 title elements are off by > 8 px). **But it cannot
+  affect this render**: `blit` sizes a sprite from its **texture**, and applies the
+  pivot only as `kf.x − pivot·(scale−100)/100` — and **all seven swoosh elements
+  are scale `(100,100)` at every keyframe**, so the term is zero.
+  ⚠️ It *would* bite `ptlogo1`/`ptlogo2`, which scale 100 → 150 during the
+  build-in. Not at rest, and not on the swoosh.
   🔴 **Ruled out for the COLOUR**: every swoosh keyframe's fade is `0x??ffffff`
   (white RGB, alpha only), no tint is non-white, and the texture decodes
-  *blue*-leaning (175,174,198). The magenta must come from blending. ❔ Not
-  diagnosed.
+  *blue*-leaning (175,174,198).
+  🟡 **What is left is the BLEND.** Size and position are the texture's own and
+  match; fade, tint and texture colour are all ruled out. Seven overlapping
+  mostly-transparent sprites (`ptlogo_back2` 5.4 % opaque, its glow 10.3 %, the
+  five `eff` segments 10–23 %, all white or warm) stacked with plain alpha-over
+  saturate to opaque white — which is exactly what we draw, and would read as
+  "thicker" against the game's thin coloured stroke. ❔ Not diagnosed.
   🔴 **Refuted:** it is *not* that our dim covers the whole frame instead of
   sitting beneath the UI — the logo reads +2.36 against a background of −0.74, so
   the paint order is being honoured.

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