revert: XTTS-Endpoint zurueck auf /tts_to_audio/

/tts_stream war bei der aktiven daswer123-Version nicht erreichbar —
Requests hingen stille, App bekam kein Audio.

Zurueck auf /tts_to_audio/ + Queue + 32x AudioTrack-Buffer. Das ist
zwar nicht echt-streaming aber stabil. Ueberlappung sollte durch die
Queue weg sein, Buffer toleriert den bursty Delivery.

Echt-Streaming-Migration spaeter mit verifizierter Server-Version
oder anderem Endpoint.

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

xtts/bridge.js

@@ -195,12 +195,13 @@ async function _runTTSRequest(payload) {
 }
 
 /**
- * Ruft /tts_stream auf — echter Streaming-Endpoint von daswer123.
+ * Ruft /tts_to_audio/ auf und streamt das Response-Body chunkweise an
- * Chunked Transfer-Encoding: Samples kommen WAEHREND XTTS rendert,
+ * den Callback. Kein echtes Server-Streaming (XTTS rendert komplett
- * nicht erst am Ende. Time-to-first-audio ~300-500ms statt 2-3s.
+ * bevor es antwortet), aber stabil und mit der Queue + grosszuegigem
+ * AudioTrack-Buffer klingt's akzeptabel.
  *
- * stream_chunk_size = Characters pro Render-Iteration.
+ * /tts_stream ist elegant, funktioniert aber nicht in allen Versionen
- * 40 = guter Kompromiss zwischen Schnellstart und GPU-Effizienz.
+ * von daswer123/xtts-api-server.
  */
 function streamXTTSAsPCM(text, language, speakerWav, onPcmChunk) {
   return new Promise((resolve, reject) => {
@@ -208,10 +209,9 @@ function streamXTTSAsPCM(text, language, speakerWav, onPcmChunk) {
       text,
       language,
       speaker_wav: speakerWav || "",
-      stream_chunk_size: 40,
     });
 
-    const url = new URL(`${XTTS_API_URL}/tts_stream`);
+    const url = new URL(`${XTTS_API_URL}/tts_to_audio/`);
     const options = {
       hostname: url.hostname,
       port: url.port,