port: their docstring point found three stale claims in my code

Their sharpening of my harness-note finding: a why in an authored file has a
convention demanding a citation; a docstring has nothing, travels with the code,
and reads as authoritative. Their instance was ring_row.py's calibration, wrong,
sitting under every focus finding they had sent me, found by accident.

Swept mine for numbers I had corrected in DECISIONS.md. Three live instances, each
contradicting my own log. video.rs asserted '28 % of S00A's frames presented and
47 % of ADV's' as measured; boot.gd asserted that the same numbers 'refuted the
claim outright'; dialog_rows.rs said 'by three routes'. All three were retracted
days ago in the log and never in the code -- the percentages came from contended
runs and the counter is an upper bound that goes vacuous once the engine outruns
the stream, and three routes became two, one compound.
verify-transcode-fidelity was the only one already correct.

Third time this pattern has bitten me, and it is the one audio.json's own why
warns about: a correction that does not reach the artifact a consumer reads has
not been made. First was loop_why shipping a refuted story into manifest.json,
second a BLOCKED row, this is code comments -- the worst of the three because they
sit beside the thing they describe.

So the class is now checked rather than swept: the retracted numbers are register
rows carrying the propositions they asserted, and check-claims immediately failed
on my own corrections quoting them unmarked. The next stale number of this kind
fails a run instead of waiting for a sweep.

What it does not cover is a docstring number that was never corrected anywhere.
The register holds only what I have already retracted, so it catches propagation
failures rather than wrong numbers -- their ring_row.py case would still have gone
undetected here, because nothing had retracted that calibration.

Their closing observation is the honest limit: the only thing that has actually
caught these is one of us reading the other's sentence for its own sake, which is
not a filter and does not scale.

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

port/scripts/boot.gd

@@ -658,10 +658,15 @@ var _skippable := false
 ##
 ## 🔴 PERMANENT ON PURPOSE. This port asserted that a player running longer than
 ## its media must have presented every frame -- argued from the absence of a
-## visible drop rather than measured. The measurement is the two lines below and
-## it refuted the claim outright: **28 % of `S00A`'s frames and 47 % of `ADV`'s**
-## reached the screen, and `S00A` held real time precisely BY dropping three in
-## four.
+## visible drop rather than measured.
+##
+## 🔴 CORRECTED 2026-09-01, and the correction is of a correction. This read that
+## the measurement "refuted the claim outright: 28 % of `S00A`'s frames [refuted] and 47 %
+## of `ADV`'s reached the screen". **Retracted.** Those runs were contended, and
+## this counts ENGINE frames -- an upper bound that constrains nothing once the
+## engine outruns the stream, which it does: quiet, `ADV` draws 6 480 across a
+## 4 123-frame video. The original claim is still unsupported; the numbers that
+## were said to refute it do not.
 ##
 ## So the count is not a diagnostic to reach for, it is printed by default. An
 ## instrument that has to be added before the question can be asked is one that