release: bump version to 0.1.8.9

Stefan-Symptom: Spotify pausiert wenn ARIA zuhoert/spricht ✓, aber
resumed nach TTS-Ende NICHT (oder nur unzuverlaessig).

Diagnose aus dem Log-Trace:

  Manual-Button-Flow:
    recording start → AudioFocus.requestExclusive (Spotify pausiert)
    STT-Endpoint    → _cleanupStreamLocal → _releaseFocusDeferred → 800ms
                      Timer → release+nudge (Spotify wuerde resumen)
    Brain processing 50s lang...
    TTS-Start       → KEIN expliziter Focus-Request! AudioTrack-USAGE_
                      ASSISTANT pausiert Spotify nur IMPLIZIT (versions-
                      abhaengig). Wir wissen nicht ob Spotify gerade
                      gepaust ist.
    TTS-End         → release+nudge — aber wenn Spotify implizit-paused
                      ist, hat es keinen sauberen Focus-Owner gesehen
                      und nudge alleine reicht nicht zum Resume.

  Wake-Word-Flow:
    Aehnliches Problem wenn state schon armed ist beim TTS-Ende
    (vom 'no-speech in conv-window'-Pfad), dann ist mein
    endConversation ein noop → releaseConversationFocus laeuft nie,
    nur die PcmPlaybackFinished-Direkt-Release greift, hat aber
    dasselbe nudge-zu-schwach-Problem.

Fix in _firePlaybackStarted (audio.ts): EXPLIZITES AudioFocus.requestDuck
beim ersten TTS-PCM-Chunk. Damit IST Spotify ueber unseren Focus
gepaused, statt nur implizit. Der spaetere release beim Pcm-Playback-
Finished ist dann das normale 'Owner ist fertig'-Pattern das Spotify
zuverlaessig zum Resume triggert.

Idempotenz: requestDuck released vorher den vorigen Focus (in Kotlin),
also harmlos wenn wake-word-acquireConversationFocus eh schon requestDuck
gerufen hat. Plus _cancelDeferredFocusRelease vorne, damit kein noch
pendender 800ms-Timer mitten in der TTS Spotify falsch resumed.

Stefan testet im Auto und auf dem Tisch — beide Spotify-Versionen
sollten mit explizitem Focus-Owner-Wechsel sauber pausieren+resumen.

android/android/app/build.gradle

@@ -79,8 +79,8 @@ android {
         applicationId "com.ariacockpit"
         minSdkVersion rootProject.ext.minSdkVersion
         targetSdkVersion rootProject.ext.targetSdkVersion
-        versionCode 10808
+        versionCode 10809
-        versionName "0.1.8.8"
+        versionName "0.1.8.9"
         // Fallback fuer Libraries mit Product Flavors
         missingDimensionStrategy 'react-native-camera', 'general'
     }

android/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aria-cockpit",
-  "version": "0.1.8.8",
+  "version": "0.1.8.9",
   "private": true,
   "scripts": {
     "android": "react-native run-android",

android/src/services/audio.ts

@@ -1518,6 +1518,18 @@ class AudioService {
       this.playbackStartTime = Date.now();
       this.currentPlaybackMsgId = this.pcmMessageId;
     }
+    // AudioFocus EXPLIZIT fuer TTS halten — sonst pausiert Spotify zwar
+    // beim Recording-requestExclusive, der wird aber 800ms nach STT-Endpoint
+    // released (Brain-Processing-Gap), und wenn dann TTS startet ist niemand
+    // mehr Focus-Owner. Spotify pausiert evtl. implizit beim AudioTrack-
+    // USAGE_ASSISTANT, aber unsere nachtraegliche release+nudge-Sequenz
+    // kann es dann nicht zuverlaessig wieder anstossen. Mit explizitem
+    // requestDuck IST Spotify sauber-via-Focus pausiert, und der Release
+    // beim PcmPlaybackFinished triggert das normale "Owner fertig → resume"-
+    // Pattern in Spotify — funktioniert versionsunabhaengig.
+    // Pending Release-Timer canceln damit der nicht mitten in der TTS feuert.
+    this._cancelDeferredFocusRelease();
+    AudioFocus?.requestDuck().catch(() => {});
     this.playbackStartedListeners.forEach(cb => {
       try { cb(); } catch (e) { console.warn('[Audio] playbackStarted listener err:', e); }
     });