port: kill the variant-link explanation for the extra sweep

The Decoder's candidate 2 -- 'a focus/variant link means only one of the pair is
active' -- is answerable from the export and the answer is no.

It looked strong: ptloop01 carries opt_link=ptloop02.rat, it is the only linked
element on the title, the field comes straight from el.focus_link, and the port
never reads it.

But surveying opt_link across the whole export splits it in two: *f.rat targets
are variant-only, everything else is a top-level element drawn in its own right.
And the second population chains across kinds -- on main_menu, ptloop01 ->
ptloop02 -> ptbtn01 -> ptbtn01f. A light sweep points at a BUTTON, which a
variant selector cannot do.

So opt_link is a chain pointer that lands on the focus variant when the element
happens to be a button, which is why it was exported as focus_link. Candidate
eliminated; the port ignoring it is not what draws the extra sweep.

Surviving smaller finding: focus_link carries two different things and is named
after one. Nothing depends on it today.

docs/port/f6-what-starts-the-sweep.md

@@ -320,3 +320,66 @@ candidate for *"the glow starts too early"*.
 
 **Not covered:** the start time of `pteff03` itself, which is still open; and the
 parent-alpha question, still 🟡.
+
+---
+
+# ❌ Unit d — the "variant link" explanation, raised and killed in one pass
+
+The Decoder's second candidate for why the game submits `ptloop01` and not
+`ptloop02` was *"a focus/variant link means only one of the pair is ever
+active"*. **That is answerable from the export, and the answer is no.**
+
+## What looked like a smoking gun
+
+`ptloop01` carries **`opt_link = "ptloop02.rat"`**, `ptloop02` carries none, and
+it is the only linked element on the title screen. The field is exported straight
+from `el.focus_link` (`crates/sylpheed-export/src/screen.rs:622`), and
+**`port/scripts/` never reads it.** An ignored variant link would have explained
+the extra sweep exactly.
+
+## ❌ And it is not a variant link
+
+Surveying `opt_link` across the whole export splits it into two populations:
+
+| target | example | is the target also a top-level element? |
+|---|---|---|
+| `*f.rat` | `ptbtn00 → ptbtn00f` | **no** — variant only |
+| everything else | `ptloop01 → ptloop02` | **yes** — both are drawn |
+
+And the second population **chains across unrelated element kinds**. On
+`main_menu`:
+
+```
+index 3   ptloop01  -> ptloop02.rat
+index 4   ptloop02  -> ptbtn01.rat
+index 10  ptbtn01   -> ptbtn01f.rat
+```
+
+**A light sweep points at a button.** A variant selector cannot do that, so
+`opt_link` is a chain pointer that happens to land on the focus variant when the
+element is a button — which is why it was exported under the name `focus_link`.
+
+> So the field does not select between `ptloop01` and `ptloop02`, and the port
+> ignoring it is not what draws the extra sweep. **Candidate eliminated.**
+
+## The smaller finding that survives
+
+**`focus_link` is carrying two different things** and the exporter names it after
+only one of them. The `*f` population is a variant; the rest is a chain. Nothing
+depends on this today — the port reads neither — but the name asserts a meaning
+the data does not support, and the next person to reach for it will reach for the
+wrong one. Worth renaming when something actually needs it; not worth a
+re-export on its own.
+
+## Where that leaves F6
+
+The lead is unchanged and unexplained: **the port draws `pteff03a`, the game's
+capture never does** — now confirmed by an exhaustive scan of every tall quad in
+1..2499 rather than a filtered subset. One of the two candidate causes is now
+eliminated from the export side, which leaves the Decoder's first: a zero-alpha
+skip suppressing the opening frames. ⚠️ That one does not obviously survive
+either — it would explain `pteff03a`'s *opening* frames, not its whole run, and
+its leaf reaches α=128 well inside the captured window.
+
+**Nothing is deleted and the renderer is unchanged**, pending one five-second
+human look: one streak, or two?