fix(audio): kickReleaseMedia auch im PCM-Pfad — re-renderte Antworten muteten Spotify dauerhaft

Stefan: ältere Nachrichten (deren Cache-WAV weg ist) gehen ueber
tts_request neu rendern → kommen als PCM-Stream zurueck → werden ueber
PcmStreamPlayer abgespielt. Beim Mute lief stopPlayback aber ohne den
Spotify-resume-Kick weil hadRnSound=false war (kein currentSound).

Jetzt: kickReleaseMedia immer in stopPlayback rufen — kostet nichts,
deckt PCM- und RNSound-Pfad ab.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

android/src/services/audio.ts

@@ -1204,10 +1204,6 @@ class AudioService {
     stopBackgroundAudio().catch(() => {});
     this.audioQueue = [];
     this.isPlaying = false;
-    // Merken: war ein react-native-sound-Sound aktiv? Dann muessen wir nach
-    // release() den Focus-Stack aufmischen (RNSound-Bug: stop+release laesst
-    // den AudioFocusRequest haengen, Spotify resumed sonst nicht).
-    const hadRnSound = !!(this.currentSound || this.resumeSound || this.preloadedSound);
     if (this.currentSound) {
       this.currentSound.stop();
       this.currentSound.release();
@@ -1236,11 +1232,10 @@ class AudioService {
     // Audio-Focus sofort freigeben — User hat explizit abgebrochen
     this._cancelDeferredFocusRelease();
     AudioFocus?.release().catch(() => {});
-    if (hadRnSound) {
-      // RNSound's haengender USAGE_MEDIA-Focus aufloesen — sonst bleibt
-      // Spotify pausiert obwohl unser Focus released ist.
-      AudioFocus?.kickReleaseMedia?.().catch(() => {});
-    }
+    // Focus-Stack immer aufmischen — bei aelteren Nachrichten die ueber
+    // tts_request (PCM-Stream) re-rendert wurden, bleibt Spotify ohne den
+    // Kick auch pausiert. Kostet nichts, deckt beide Pfade ab.
+    AudioFocus?.kickReleaseMedia?.().catch(() => {});
   }
 
   // --- Status & Callbacks ---