method: correct my characterisation of the port's pacing test -- the overrun is the evidence

I called their video timing the skippable kind. A player dropping frames to keep up
finishes early or on time; theirs ran 146.6 s for 137.44 s of media, which is
inconsistent with having skipped back onto schedule. So it is a time-to-consume
measurement after all, and their withdrawal applies only to the audit use.

Refinement they did not claim: running long proves it did not skip ENOUGH to stay
on schedule, not that it skipped nothing -- so +6.7 % is a lower bound on the
deficit, which favours their conclusion.

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

docs/re/METHOD.md

@@ -2464,10 +2464,24 @@ focus claim — recovered only because the narrow reader still worked on it.
 
 `sylpheed-port` withdrew their own pacing test and the reason generalises. They
 timed a video player against media length and got **−0.5 %**, tight and
-reproducible — and useless, because *the player picks frames by elapsed clock
-time*. A uniformly starved clock presents fewer frames per real second and still
-finishes in exactly the media's duration. **The failure produces the appearance of
-success.**
+reproducible — and useless *as an audit*, because a player that picks frames by
+elapsed clock time stays on schedule by doing less work: a uniformly starved clock
+presents fewer frames per real second and still finishes in exactly the media's
+duration. **The failure produces the appearance of success.**
+
+🔴 **CORRECTED 2026-08-30, same day — I described their measurement as the
+skippable kind and that was wrong.** They pointed out that the *overrun is itself
+the evidence*: a player dropping frames to keep up finishes **early or on time**,
+and theirs ran **146.6 s for 137.44 s of media**. Running long is inconsistent with
+having skipped its way back onto schedule. So their `ADV` +6.7 % and `S00A` −0.5 %
+belong to the time-to-consume class after all — the class endorsed below — and the
+withdrawal applies only to the *audit* use, not to the load-starvation finding.
+
+⚠️ One refinement they did not claim and I would not grant: running long proves the
+player did not skip **enough to stay on schedule**, not that it skipped *nothing*.
+Any dropping that did occur makes the true decode time longer still, so **+6.7 % is
+a lower bound on the deficit**. That cuts in favour of their conclusion, not
+against it.
 
 ⚠️ My audio measurement survives that objection, and it is worth being precise
 about *why*, because the two look alike: `input_buffer_read_offset` is a