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.