fix(audio): _delayedMix never initialized — one NRE line behind the 'known failure', the class hang, AND the log flood; loopback gain now honest

The creator-declared known failure (Mix_HonorsProviderGains) and AudioPipelineTests'
standalone hang shared ONE root cause, born in TASK 22: AudioMixer.FillAndMix
dereferenced _delayedMix (declared float[]? , never assigned) as delayed.Length —
every live-mix tick NRE'd before the pipe write, so NO audio ever reached the wire
(tests starved -> hung/fail; app -> swallowed catch logged only ex.Message, 10ms
flood). Now: ctor-allocated + null-check, catch logs WITH stack via AppLog and is
throttled 5s, and a cancelled token breaks out before logging.

Bonus contract fix: AudioGainProvider.LoopbackGain returned unity on a disproven
premise ('loopback scales with endpoint volume'). The creator's tonight observation —
volume at 20%, meter pegged — proves the WASAPI tap is pre-endpoint-volume, so the
mixer must multiply by GameAudioVolume for stream honesty (this is what ai.md always
specified; the 'failing' test encoded the same and was RIGHT).

AudioPipelineTests: 25/25 in 26ms, standalone, no hang. Known-failure count: ZERO.
ai.md tests paragraph rewritten (no more suite-total claims, both ex-'knowns'
explained); TASK 22 regression recorded; MyMistakes: the known-failure-label rules.

MyMistakes.md

@@ -124,3 +124,25 @@ with `#Name`) + panel properties (`IsHitTestVisible/Opacity/children/actual size
    test process shares `%APPDATA%\ytLlive\startup.log` with the real app: lines like
    `camera 'test-camera' failed` are test noise, not DB state — to check pollution, query
    the DB directly (`python3 sqlite3`, `SELECT DeviceId FROM Webcam`), not the log.
+
+## A "known failure" label without a recorded cause = a bug on life support
+
+(2026-09-01, the audio triple-take) One line — `_delayedMix` (nullable, added by TASK 22,
+never initialized) dereferenced as `delayed.Length` — produced THREE symptoms that lived in
+the map as two separate "pre-existing, do-not-chase" entries: (a)
+`Mix_HonorsProviderGains…` "known failure", (b) `AudioPipelineTests` hangs when run at all
+(a test reading a named pipe with no writer blocks — hung test ≠ flaky test, it's a starved
+producer), (c) startup.log flooded "Audio live loop error" every 10ms (the mixer loop caught
+and logged only `ex.Message` — stack thrown away).
+
+Rules derived:
+1. NEVER label a test "known/pre-existing" without writing WHY (exception type + first app
+   frame). An unexplained known-failure is deferred archaeology that hardens into fog.
+2. A test that waits on IPC + a producer whose output vanished are usually ONE bug — look
+   for the producer before blaming the test.
+3. Catch-and-log-swallow of `ex.Message` hides root causes; log with stack (`AppLog.Write(ex,
+   ...)`) and throttle (5s) instead of dropping or flooding.
+Bonus: the "failing" test encoded the MAP's contract (`loopbackGain = GameAudioVolume`); the
+code had drifted to unity on a disproven premise (loopback capture does NOT follow endpoint
+volume — creator's 20%-volume/pegged-meter observation killed it). The test was right all
+along — failing tests may be the last honest witnesses; interrogate, don't pardon.