fix: XTTS nutzt direkt /tts_to_audio/ — /tts_stream nicht verfuegbar

XTTS-Server (daswer123) im API-Modus antwortet auf /tts_stream mit:
  HTTP 400: "HTTP Streaming is only supported for local models"

Das Feature braucht MODE=local in der XTTS-Config (Modell direkt im
Server-Prozess). Userbetreibt im Remote-Modus → kein Streaming.

Der try /tts_stream + fallback /tts_to_audio Ansatz war reine Ver-
schwendung: jeder Request wartete 6ms auf 400, bevor der Fallback
griff. Jetzt geht's direkt an /tts_to_audio/.

Kein echtes Streaming, aber:
- Queue sorgt fuer sequentielle Verarbeitung (kein Overlap mehr)
- 32x AudioTrack-Buffer faengt den bursty Response ab
- aria-bridge spiegelt audio_pcm nicht mehr (kein Doppel-Audio)

Wenn User spaeter /tts_stream haben will:
  XTTS-Server mit MODE=local oder --streaming-mode starten,
  dann kann man /tts_stream als primary einfuehren.

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

xtts/bridge.js

@@ -157,24 +157,16 @@ async function _runTTSRequest(payload) {
       });
     };
 
-    // Erst /tts_stream (GET) versuchen — echter Streaming, schnell.
+    // /tts_stream funktioniert nur bei XTTS im local-Modus. daswer123 im
-    // Bei Fehler Fallback auf /tts_to_audio/ (POST) damit Audio trotzdem kommt.
+    // Remote-API-Modus antwortet mit 400 'HTTP Streaming is only supported
-    try {
+    // for local models'. Wir nutzen stabil /tts_to_audio/ (batch render,
-      await streamXTTSAsPCM(
+    // dann Response-Body chunkweise als PCM).
-        cleanText,
-        language || "de",
-        hasCustomVoice ? voiceSample : null,
-        onChunk,
-      );
-    } catch (streamErr) {
-      log(`/tts_stream fehlgeschlagen (${streamErr.message}) — Fallback auf /tts_to_audio/`);
     await streamXTTSBatch(
       cleanText,
       language || "de",
       hasCustomVoice ? voiceSample : null,
       onChunk,
     );
-    }
 
     // Am Ende: final-Flag damit App weiss "fertig" und Cache geschrieben werden kann
     if (pcmMeta) {