fix(wake-word): manueller Mikro-Stop beendet Konversation, zurueck zu armed

Bug: Nach Wake-Word "Computer" → conversing → User drueckt manuell den
Mikro-Button um zu stoppen → Audio wird gesendet, aber state bleibt
'conversing'. Nach ARIAs Antwort oeffnet sich automatisch wieder das
Mikro fuer Multi-Turn — obwohl der User explizit den Knopf gedrueckt
hat um zu signalisieren "ich bin fertig".

Fix: Im handleVoiceRecording (= manueller Stop ueber VoiceButton) wird
nach dem Send wakeWordService.endConversation() gerufen wenn aktuell
in conversing-State. Das setzt zurueck auf 'armed' und startet
openWakeWord wieder fuer passives Lauschen. ARIAs Antwort kommt durch,
TTS spielt, aber resume() ist dann no-op weil state schon 'armed'.

Bei VAD-Auto-Stop (silence-callback im Wake-Word-Pfad) bleibt das
Multi-Turn-Verhalten unveraendert — das ist die "natuerliche" Pause
und passt zum Konversations-Modus.

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

android/src/screens/ChatScreen.tsx

@@ -770,6 +770,17 @@ const ChatScreen: React.FC = () => {
       ...(location && { location }),
     });
     scheduleStaleAudioCleanup(audioRequestId, result.durationMs);
+
+    // Manueller Mikro-Stop waehrend Wake-Word-Konversation: User hat explizit
+    // den Knopf gedrueckt → er moechte nicht in den automatischen Multi-Turn-
+    // Modus, sondern nach ARIAs Antwort zurueck zu passivem Wake-Word-Lauschen.
+    // Bei VAD-Auto-Stop (Wake-Word-Pfad) laeuft das ueber den silence-callback
+    // und endet mit resume() — der manuelle Stop hier ist der "ich bin fertig"-
+    // Knopf.
+    if (wakeWordService.isConversing()) {
+      console.log('[Chat] Manueller Stop in Konversation → endConversation, zurueck zu armed');
+      await wakeWordService.endConversation();
+    }
   }, [getCurrentLocation, interruptAriaIfBusy, scheduleStaleAudioCleanup]);
 
   // Datei auswaehlen → zur Pending-Liste hinzufuegen