fix(app): Aufnahme-Sperre fragt den Socket statt den gemerkten Zustand

Beweis aus app.log 02.10 01:22: beim Aufnehmen fehlte 'bg.start slot=rec' —
die Aufnahme wurde abgelehnt, BEVOR sie begann. Ursache ist die in 10e7faa
eingefuehrte Sperre 'ohne Verbindung nicht aufnehmen': sie prueft den gemerkten
Zustand, und der steht wegen des Zombie-Bugs faelschlich auf 'disconnected',
obwohl die Verbindung laeuft (TTS kam ja an). Ergebnis: Stefan konnte gar nicht
mehr sprechen — die Sperre hat das Problem verschlimmert statt es zu verhindern.

rvs.isSocketOpen() fragt jetzt ws.readyState direkt; audio.ts nutzt das. Damit
ist die Sperre immun gegen falsche Zustandsmeldungen und blockt nur, wenn der
Socket wirklich zu ist. tsc: 0 Fehler.

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

android/src/services/audio.ts

@@ -1161,8 +1161,12 @@ class AudioService {
     // start, Chunks und end waren weg, die Bubble verschwand, und erst der
     // zweite Versuch klappte (da war der Reconnect durch). Nachtraeglich
     // gepuffertes Audio waere sinnlos: die STT-Sitzung laeuft in Echtzeit.
-    if (rvs.getState() !== 'connected') {
-      console.warn('[Audio] startStreamingRecording: RVS nicht verbunden (state=%s)',
+    // WICHTIG: den SOCKET fragen, nicht den gemerkten Zustand. Der kann
+    // faelschlich 'disconnected' sein, obwohl die Verbindung laeuft (Zombie) —
+    // dann wuerde hier jede Aufnahme abgelehnt, bevor sie beginnt, und der
+    // Nutzer kann gar nicht mehr sprechen.
+    if (!rvs.isSocketOpen()) {
+      console.warn('[Audio] startStreamingRecording: Socket nicht offen (state=%s)',
                    rvs.getState());
       return { requestId: '', ok: false, error: 'not-connected' };
     }