docs(issues): #0054 — Safari sent unfiltered, fixed and verified in v0.5.4

LiveKit's setProcessor swaps the sender track behind an optional chain; when
Safari's timing leaves the sender unset at that instant, the swap is skipped
silently and the raw microphone stays on the wire. The fork now verifies and
enforces the swap. Also records two instructive diagnostic dead ends: a sine
tone is noise to a speech model, and two devices in one room invalidate any
listening test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md

@@ -327,3 +327,34 @@ die Wiederauffindbarkeit der Einstellung gehoert in die Anwenderdoku.
 
 Erst danach: Tor oeffnen + UI einblenden (v0.5.3). Alternativ bleibt Abbruch (Option C)
 jederzeit moeglich — v0.5.2 ist fuer alle Nutzer verhaltensgleich mit v0.5.1.
+
+## Nachtrag 2026-08-17/18: Safari sendete ungefiltert — behoben in v0.5.4
+
+Nach der Tor-Oeffnung (v0.5.3) meldete sorb: Filter wirkungslos, **Staerke 0-100 ohne jeden
+Unterschied**, sauberer Alleintest (Hoergeraet gemutet). Auf anderen Rechnern (Chromium-Familie)
+funktionierte derselbe Stand. Messungen mit einem lokalen Pruefstand (Playwright, echter
+LiveKit-`setProcessor`-Pfad, Sprachsignal mit Klick-Transienten) ergaben: Prozessor und Modell
+arbeiten korrekt — Sprache passiert, Klicks verschwinden.
+
+**Ursache:** LiveKits `setProcessor` tauscht den Sender-Track per
+`this.sender?.replaceTrack(processedTrack)`. Ist der Sender in dem Moment nicht am Track
+(Safari-Timing beim LocalTrackPublished-Event), wird der Tausch **stumm uebersprungen** — der
+Prozessor laedt seine 23 MB, meldet Erfolg, und das rohe Mikrofon bleibt auf der Leitung.
+Viertes Vorkommen des Sitzungsmusters "meldet Erfolg, ist aber blind", diesmal in Fremdcode
+(das `?.` verschluckt den Fehlschlag).
+
+**Zwei Irrwege der Diagnose, festgehalten weil lehrreich:**
+- Ein synthetischer Sinuston als "Stimme" liess den Filter wie einen Totalausfall aussehen —
+  fuer ein **Sprach**-Modell ist ein Ton Rauschen, die Daempfung bis zum Limit war korrektes
+  Verhalten am falschen Signal. Messsignale muessen dem Modell entsprechen.
+- Zwei Geraete im selben Raum machen jeden Hoertest wertlos (Tastatur akustisch und ueber das
+  zweite, ungefilterte Mikro hoerbar). Der brauchbare Alleintest: Hoergeraet **gemutet** mit
+  Kopfhoerer.
+
+**Fix (threadnet-call `fee9866`, embedded `.12`, ThreadNet-Web v0.5.4):** Nach dem Anhaengen
+wird verifiziert, dass der RTCRtpSender den gefilterten Track traegt — notfalls wird auf den
+Sender gewartet und der Tausch explizit erzwungen. Die Konsolen-Zeile weist den Zustand aus:
+`Sendepfad gefiltert: ja/NEIN`. Drei Tests decken die Sender-Faelle ab.
+
+**Test sorb 2026-08-18 (Safari als sendender Client): bestanden.** Damit ist der Filter auf
+beiden Engine-Familien nachgewiesen. Weiterhin offen und bewusst vertagt: Telefontest (mobil).