port: transcribe the sweeps' additive blend, and re-run my own menu-looping evidence with it

ui-blend-mode-measured.md names both rotated sweep strips additive in the same row
as the frames. Those are ptloop01/ptloop02 here, now in additive_elements for both
measured screens. It changes nothing visible: on the menus the port runs the leaf
group once and parks it off-screen, and suppressing both sprites at leaf-time 100,
200 and 300 changes 0 pixels each time. It is in the file because it is measured.

Refutation attempt on their identification, and it survives with a number of mine.
The automatic matcher reports "no match" for those two draws; they rest on one
control reproducing heights 1134 and 1303. Rendering the menu at a phase where the
sweeps are on screen and suppressing them gives a footprint 884 px wide against
their 889.6 -- 0.6 % apart, derived without using their number. The heights differ
as they should: my bbox is clipped by the screen, theirs is the full quad extent.

The blend was a confound in my own earlier evidence. loop_leaf_why scoped looping
to the title partly on a phase sweep of mine that drew the sweeps ALPHA-OVER, so
an on-screen sweep was composited wrongly and then scored against the capture. Re-
run with additive and looping enabled for the menu, through a scratch export root
so the repo was untouched: parked 0.0208 %, phase 150 on-screen 0.0851 % with the
sweeps painting 58 027 px, other on-screen phases 0.086-0.122 %.

The conclusion held and got stronger -- 3x with the wrong blend, 4-6x with the
right one -- so the scoping stays and the correction is what is recorded. Still one
capture, and best-match is still weak evidence for an absence.

And a reading of the new log that I did not make: it shows both sweeps SUBMITTED
on the main menu in every frame group, which is not evidence they animate there. A
quad parked off-screen at x=1521 is still a draw call. The log settles the blend
and not the visibility, and both questions arrived in the same artefact.

authored/rendering.json

@@ -100,18 +100,55 @@
   "match' is a weak instrument for an absence. Two weak signals in opposite",
   "directions is a reason to scope, not to pick.",
   "",
-  "What settles the menu: a direct capture of it, which the Decoder has offered."
+  "What settles the menu: a direct capture of it, which the Decoder has offered.",
+  "",
+  "🔴 RE-MEASURED 2026-08-31, BECAUSE THE EVIDENCE ABOVE WAS TAKEN WITH THE WRONG",
+  "BLEND. The phase sweep that produced '0.061 % off-screen, 0.183 % mid-screen'",
+  "drew the sweeps ALPHA-OVER. They are additive -- measured off the running game",
+  "the same day (`additive_elements`) -- so an on-screen sweep composited the wrong",
+  "way was being scored against the capture, and 'mid-screen is worse' could have",
+  "been an artefact of my own compositing rather than of the sweeps being absent.",
+  "",
+  "Re-run with additive sweeps and looping switched on for the menu, against",
+  "`live-main-menu.png`:",
+  "",
+  "    phase   0  0.0208 %   sweeps paint 0 px -- off screen",
+  "    phase 150  0.0851 %   sweeps paint 58 027 px, bbox 884x720",
+  "    phase 300  0.0205 %   sweeps paint 0 px -- off screen",
+  "    phase 75 / 225 / 375 / 450 / 525: 0.086..0.122 %",
+  "    run-once-and-park, which is what the port ships: 0.0208 %",
+  "",
+  "✅ THE CONCLUSION HELD AND GOT STRONGER. The ratio was 3x with the wrong blend",
+  "and is 4-6x with the right one, and the absolute numbers improved everywhere.",
+  "The capture still matches best with the sweeps NOT VISIBLE. So this entry stays",
+  "scoped to the title, and the correction is recorded rather than the scoping",
+  "changed.",
+  "",
+  "⚠️ It is still one capture and 'best match' is still a weak instrument for an",
+  "absence -- that caveat is not repaired by fixing the blend, only cleared of one",
+  "confound.",
+  "",
+  "📌 AND THE NEW DRAW LOG DOES NOT SETTLE IT EITHER, though it looks like it",
+  "should. `docs/re/captures/ui-draws/blend-main-menu-2026-08-31.log` shows both",
+  "sweep strips SUBMITTED on the main menu, in every frame group. That is not",
+  "evidence they animate there: a quad parked off-screen at x=1521 is still a draw",
+  "call. A DRAW IS NOT A VISIBLE ELEMENT, and reading that log as 'the sweeps run",
+  "on the menu' would have contradicted the pixels for no reason."
  ],
  "loop_leaf_kind": "measured",
  "additive_elements": {
   "main_menu": [
    "pteff12",
    "ptframe1",
-   "ptframe2"
+   "ptframe2",
+   "ptloop01",
+   "ptloop02"
   ],
   "extras": [
    "pteff20",
-   "ptframe3"
+   "ptframe3",
+   "ptloop01",
+   "ptloop02"
   ]
  },
  "additive_elements_why": [
@@ -136,6 +173,21 @@
   "menu -- 12 draws additive and 18 alpha-over. The frames and `ptbase` share a",
   "shader. Only the blend register differs.",
   "",
+  "`ptloop01` and `ptloop02` are the two ROTATED SWEEP STRIPS, added 2026-08-31.",
+  "`docs/re/structures/ui-blend-mode-measured.md`'s summary table names them",
+  "additive in the same row as the frames, and their control 1 identifies them: the",
+  "NDC->pixel conversion reproduces 1134 and 1303 px, two heights measured by a",
+  "different tool in a different session (`data/title-sweep-drawn-at-rest.txt`), on",
+  "BOTH screens. So this is an identification with an independent check behind it,",
+  "not a name match -- the automatic matcher reports 'no match' for these two.",
+  "",
+  "⚠️ AND IT CHANGES NOTHING VISIBLE TODAY, which is why it is worth writing down.",
+  "On the menus the port runs the leaf group ONCE and parks it off-screen, so these",
+  "two paint no pixels at any pose the port can be put in (checked: suppressing",
+  "both sprites at leaf-time 100, 200 and 300 changes 0 pixels). The entry is here",
+  "because it is measured, not because it does anything. What it DOES do is fix the",
+  "instrument for the menu-looping question -- see `loop_leaf_on_screens_why`.",
+  "",
   "⚠️ EVERY ID HERE IS A MEASURED DRAW, and the list stops where the measurement",
   "does. THREE THINGS ARE NOT IN IT:",
   "",