re: confirm the two sweeps loop at 720:600, and close the open period

Pre-registered 1.2000 from the declared leaf loops before measuring.
Measured 1.1967 (0.28%) in f6b and 1.1841 (1.33%) in f6, as a ratio inside
each capture so no clock enters -- which is why runs differing 2x in frames
agree. f6b happens to pace at one frame per leaf unit: 600 frames for 600
declared units, 718 for 720.

First test pteff03a's declared timeline has ever had. It could have failed
against me: the flattering reading of unit 11's batched draw is one
traveller driving both quads, which gives equal periods. It does not.

Also closes "one wrap per capture, period not obtained", which has been open
all week -- both leaves give a complete boundary-to-boundary cycle in both
existing logs. The truncating reader saw one quad, so it could see only one
of the four cycles already on disk.

Refutation aimed at the port: running both leaves at one rate leaves the
strips locked and drifting ~118 units per cycle from the game.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/re/f6-two-leaf-periods-confirmed.md

@@ -0,0 +1,60 @@
+# ✅ The two sweeps loop at **720:600** — `pteff03a`'s timeline confirmed
+
+**Question:** do the two glowing strips cycle at different rates?
+
+**What the human looks at:** watch the title for a while. The two strips **drift
+out of sync** — one comes round slower. Pass = they separate. Fail = they stay
+locked together.
+
+**What this does NOT cover:** their alpha curves, and the `0x70000` kind bits.
+
+**Instrument:** ⟨capture⟩ ×2, read with `read_draws.py`. Prediction registered in
+[`f6-two-leaf-periods-prereg.md`](f6-two-leaf-periods-prereg.md) **before**
+measuring.
+
+## Measured — and it is the first test `pteff03a`'s timeline has ever had
+
+`pteff03` declares a 600-unit loop, `pteff03a` **720**. Predicted ratio
+**1.2000**:
+
+| | `pteff03` period | `pteff03a` period | ratio | error |
+|---|---|---|---|---|
+| `f6b` | 600 frames (577→1177) | 718 frames (581→1299) | **1.1967** | **0.28 %** |
+| `f6` | 1168 frames (746→1914) | 1383 frames (755→2138) | **1.1841** | 1.33 % |
+
+The ratio is taken inside each capture, so no clock or frame rate enters — which
+is why the two runs agree despite differing 2× in frames.
+
+**`f6b` also happens to pace at one frame per leaf unit**, making it directly
+readable: **600 frames for 600 declared units, 718 for 720**. That is a
+coincidence of that run's pacing, not a property of the game, and it is quoted
+because it is legible rather than because it is portable.
+
+## Why this could have failed against me
+
+`pteff03a` was found only in [`unit 11`](f6-unit11-pteff03a-IS-drawn.md), as the
+second quad of a **batched draw** — and the flattering reading of a batched draw
+is that one traveller drives both quads, which would give **equal periods**. The
+declared data says otherwise and the capture agrees with the declaration.
+
+So the two quads are two elements with two timelines, not one element drawn
+twice. That is now measured rather than inferred from the leaf table.
+
+## 🔴 And it closes the period that has been open all week
+
+Every earlier attempt reported "one wrap per capture, period not obtained". It
+was obtained here without a new capture: **both leaves give a complete
+boundary-to-boundary cycle in both existing logs.** The old reader saw one quad,
+so it could see only one of the four cycles on disk.
+
+## Refutation attempt
+
+Against the port: they now draw both sweeps, and **if they run both leaves at one
+rate the strips will stay locked and drift apart from the game within a single
+loop** — ~118 units of separation per cycle, growing. Flagged; I cannot test
+their renderer from here, so this is a prediction for them to check, not a result.
+
+## Not settled
+
+* The `0x70000` kind bits (160 elements, nothing blocked on them).
+* The per-cycle phase fit for the post-wrap alpha decomposition.