foundry, check-mix: say who actually heard what, and stop one mode lying

66318b6e's comment and test docstring both claimed PLN heard the polled-loop
stutter. He did not. The Foundry server was not running: port 8765 was
another project's http.server, established two steps after the fix landed.
The bug is real and of exactly the reported shape, and it stays fixed - but
attributing a fix to a symptom it did not cause is how a wrong diagnosis
becomes documentation, which is this morning's -inf-faders mistake again.
Both places now say where it came from. The commit message is history and is
left alone.

And check-mix's --arm table called an unarmed `Mix` route "not recorded, by
choice" while --mix blocks on precisely that. Two modes of one tool must not
disagree about the same route.

tools/check-mix.py

@@ -491,6 +491,10 @@ def main() -> int:
                 shown, note = "n/a", "a bus — Ardour cannot arm it"
             elif armed:
                 shown, note = "YES", "rec-safe ON — cannot be armed" if safe else ""
+            elif name == MIX_ROUTE:
+                # Not "by choice": --mix BLOCKS on an unarmed Mix route. Two
+                # modes of one tool must not disagree about the same route.
+                shown, note = "no", "the mix capture, unarmed — see --mix"
             else:
                 shown, note = "no", ("records no stem" if name.startswith("Tidal")
                                      else "not recorded, by choice")

tools/foundry/tests/test_audition_loop.py

 """The audition loop must live in the audio thread, not on a `timeupdate` poll.
 
-THE BUG THIS TEST GUARDS (2026-09-25, mid-rehearsal)
-PLN: *"i hear a chopped thing as if play/pause toggle every 200ms?"*
+THE BUG THIS TEST GUARDS (found 2026-09-25)
+Found while hunting a stutter PLN reported — *"i hear a chopped thing as if
+play/pause toggle every 200ms?"* — and it is NOT the one he heard: the Foundry
+server was not running at the time, so nothing here was making sound. It is a
+real latent bug of exactly that shape, and it is fixed because it was found.
+Saying so matters: attributing a fix to a symptom it did not cause is how a
+wrong diagnosis becomes documentation.
 
 The loops panel looped an `<audio>` element from a `timeupdate` listener:
 
@@ -13,8 +18,7 @@ The loops panel looped an `<audio>` element from a `timeupdate` listener:
 from `min_len_s` up, and those are SUB-SECOND — so the poll interval was the
 same length as the thing being looped. Playback overshot `end` by up to a whole
 region and only snapped back on the next tick, and each snap was a seek on a
-streamed element, which rebuffers and gaps the seam. A 4 Hz stutter, exactly as
-described.
+streamed element, which rebuffers and gaps the seam. A 4 Hz stutter.
 
 There is no poll rate that fixes this, which is why the fix is a deletion: an
 `AudioBufferSourceNode` with `loop`/`loopStart`/`loopEnd` loops in the audio

tools/foundry/ui/index.html

@@ -227,8 +227,13 @@ const BUF={};                 // decoded AudioBuffer cache, keyed slug/name
 // slices of 0.25 s to 2.0 s (engine/loops.py:322) — so the poll interval was
 // the same length as the thing being looped. Playback ran past `end` and only
 // snapped back on the next tick, and every snap was a SEEK on a streamed
-// element, which rebuffers and leaves a gap at the seam. PLN, mid-rehearsal:
-// "i hear a chopped thing as if play/pause toggle every 200ms". It was, at 4 Hz.
+// element, which rebuffers and leaves a gap at the seam.
+//
+// PROVENANCE, because the first version of this comment got it wrong: this was
+// found while hunting a stutter PLN reported on 2026-09-25 ("as if play/pause
+// toggle every 200ms"), and it is NOT what he heard — the Foundry server was
+// not running at the time; port 8765 was another project's http.server. It is
+// a real latent bug of exactly that shape, fixed because it was found.
 //
 // An AudioBufferSourceNode loops in the audio thread between `loopStart` and
 // `loopEnd`: sample-accurate, gapless, no polling and no seeking, and correct