port: the two sweep leaves DO run on their own periods -- refutation not landed

The Decoder raised it and could not test it: if the port ran both leaves on one
rate they would stay locked and drift ~118 units per cycle. The leaves declare
600 and 720.

Pre-registered, then measured on a real boot. At raw leaf clock 4873:
  pteff03  span 600 -> measured 72.6  (fposmod 73)
  pteff03a span 720 -> measured 552.6 (fposmod 553)
The port takes each span from that leaf's OWN keyframes, so they were never
locked. 17748 samples, title clock reaching 9745 -- the sweep loops 162 s in.

🔴 Two false alarms of mine on the way, both the same mistake:
 - used --time (which sets frozen and bypasses the holding clamp BY DESIGN) to
   ask about RUNNING behaviour, and nearly reported the whole title vanishing
   past t=250. On a real boot settle_window [160,236,198] clamps to t=198 and a
   filmed frame at view_units 6733 shows the complete title.
 - read a probe going quiet as the feature stopping. Two runs ended at u~236;
   that was the RUN ending, not the sweep. With a film attached the same probe
   reaches 9745.

Both are the frozen-sweep lesson again: the diagnostic that pins the clock cannot
answer a question about the clock running, and an instrument going quiet is not
the subject going quiet -- the same shape as a count of zero meaning only that
nothing reached the reader.

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

@@ -520,3 +520,42 @@ both cases the argument was valid and the *inputs to the summary* were wrong. No
 amount of re-reading the claim finds that; only re-running it does. It is the
 argument for re-running over re-checking, and it is why the two findings flagged
 as unverified above were re-run rather than defended.
+
+---
+
+# ❌ A refutation aimed at this renderer, measured and NOT landed
+
+The Decoder raised it and could not test it from their side: *"if your renderer
+runs both leaves on a single rate, the two strips stay locked together and drift
+from the game by ~118 units per cycle, growing without bound."* The two leaves
+declare **600** and **720** unit loops.
+
+**Pre-registered, then measured on a real boot** via `--probe-leaf`. At a raw leaf
+clock of 4873:
+
+| leaf | span | measured `leaf_t` | `fposmod(4873, span)` |
+|---|---|---|---|
+| `pteff03` | 600 | **72.6** | 73 |
+| `pteff03a` | 720 | **552.6** | 553 |
+
+The port takes each leaf's span from **its own keyframes** — `span = max(k.t)`
+over `fe.keyframes` — so the two were never locked. **17 748 probe samples, title
+clock reaching 9 745**, i.e. the sweep is still looping 162 seconds in.
+
+## 🔴 Two false alarms of my own on the way there, both from the same mistake
+
+1. **I used `--time` to ask a question about running behaviour.** It sets
+   `frozen`, which by design bypasses the `holding` clamp, so the title read as
+   *empty* past t=250 and I nearly reported the whole title vanishing. On a real
+   boot it does not: `settle_window` is `[160, 236, 198]`, the elements clamp to
+   t=198, and a filmed frame at `view_units 6733` shows the complete title.
+2. **I read a probe stopping as the feature stopping.** Two runs ended at
+   u≈236 and I took that as the sweep dying at settle. It was the run ending —
+   without `--film` the boot exits sooner. With a film attached the same probe
+   reaches 9 745.
+
+📌 Both are the frozen-sweep lesson wearing new clothes: *the diagnostic that
+pins the clock cannot answer a question about the clock running*, and *an
+instrument going quiet is not the subject going quiet*. The second is the same
+shape as the Decoder's own absence-of-a-quad bug — a count of zero says only that
+nothing reached the reader.