re: withdraw "the sweep rate matches the disc" -- two errors that cancelled

sylpheed-port corrected the disc figure I compared against: the leaf's final
segment HOLDS, so a cycle length is not a motion duration. Verified from the
disc rather than accepted -- pteff03 moves over t=0..540 of a 600-unit cycle
(4.000 px/unit, not 3.600) and pteff03a over 0..630 of 720 (4.063, not 3.556).

Checking that sent me back to my own measurement, which was worse. "6-7
px/frame" came from eyeballing deltas between consecutive APPEARANCES in a
capture that skips frames, so a delta of 7 often spans two frames. A
least-squares fit of x against frame over all 132/112 points gives +4.287 and
-4.348 px/frame, with rms residuals of 3.6 and 3.3 px.

So the confirmation I reported was a prediction 20 % too low meeting a
measurement 50 % too high. Neither number was right and the agreement was an
artefact of both being wrong -- which is the most dangerous form of agreement in
this corpus, because nothing about it looked suspicious.

The corrected numbers say something larger than the claim they replace. Measured
against declared: 4.287/4.000 = 1.072 units per frame, and 4.348/4.063 = 1.070.
Two independent strips with different cycle lengths and different declared rates
agree to three significant figures. Q1 establishes 2 units per RENDERED frame for
top-level elements. So either a nested leaf record advances at about half the
top-level rate, or Q1's factor does not apply to nested records. Measured, not
explained, and flagged as deserving its own iteration because Q1 is load-bearing.

One untested candidate recorded: 1 unit per 1/30 s of game time against the
~28.5 fps this corpus measures for the idle title gives 1.053, close to 1.07.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

crates/sylpheed-formats/examples/ptloop_leaf_extent.rs

@@ -39,11 +39,25 @@ fn main() {
                         if !sys.contains(&k.scale_y) { sys.push(k.scale_y) }
                     }
                 }
+                // A CYCLE LENGTH IS NOT A MOTION DURATION. Find the last t at
+                // which x still changes: sylpheed-port reports the final segment
+                // HOLDS, which would make px/unit larger than cycle-based maths.
+                let mut last_move = 0u32;
+                let mut prev = None;
+                for t in 0..=span {
+                    if let Some(k) = le.pose_at(t) {
+                        if prev.map_or(false, |p| p != k.x) { last_move = t }
+                        prev = Some(k.x);
+                    }
+                }
                 let w = (le.pivot_x * 2) as i64;
                 println!("    leaf {:<12} pivot {}x{}  quad w={w}  x track {lo} .. {hi}  \
                           (centre {} .. {})  scale_x {:?} scale_y {:?}",
                          le.name, le.pivot_x, le.pivot_y,
                          lo + le.pivot_x as i64, hi + le.pivot_x as i64, sxs, sys);
+                println!("      motion ends at t={last_move} of a {span}-unit cycle ->                           {:.3} px/unit over the MOVING span (vs {:.3} over the cycle)",
+                         (hi - lo) as f64 / last_move.max(1) as f64,
+                         (hi - lo) as f64 / span as f64);
             }
         }
     }