Add XTTS primary voice with Piper fallback

docs/INSTALLATION.md

@@ -84,7 +84,9 @@ OpenSSH-Dienst des Hosts.
 
 Die TTS-Verbindung wird für eine frische Open-WebUI-Datenbank automatisch als
 OpenAI-kompatibler Audio-Endpunkt des Routers vorbelegt. Der Router reicht sie
-intern an Piper weiter; Port 8085 wird nicht am Host veröffentlicht. Ein
+intern an das TTS-Gateway weiter. Primär spricht XTTS-v2 mit `Annmarie Nele`
+auf der RTX 3060; bei Fehlern oder Queue-Timeout übernimmt Piper auf der CPU.
+Der Port 8085 wird nicht am Host veröffentlicht. Ein
 Restore setzt zusätzlich die vier persistenten Audiofelder gezielt neu, damit
 alte Werte wie `tts-1` oder `coral` die Compose-Vorgaben nicht überstimmen. Ein
 Ende-zu-Ende-Test ohne Ausgabe des API-Schlüssels:
@@ -95,9 +97,17 @@ curl -fsS http://127.0.0.1:8081/v1/audio/speech \
   -H "Authorization: Bearer $ROUTER_API_KEY" \
   -H 'Content-Type: application/json' \
   -d '{"model":"piper","voice":"alloy","input":"Hallo von Athena.","response_format":"mp3"}' \
-  -o /tmp/athena-piper-test.mp3
+  -o /tmp/athena-tts-test.mp3
 ```
 
+Der beibehaltene API-Name `piper/alloy` ist eine Kompatibilitätsschnittstelle;
+bei gesundem XTTS stammt die Ausgabe von `Annmarie Nele`. Der interne Status
+des TTS-Gateways nennt `last_backend`, `primary_ready`, `fallback_ready` und
+die Zahl der Piper-Rückfälle. Ein Fallback-Test stoppt ausschließlich XTTS,
+erzeugt einen synthetischen Satz über denselben Router-Endpunkt und startet
+XTTS anschließend wieder. OpenWebUI und Router müssen dafür nicht geändert
+oder neu gestartet werden.
+
 Zusätzlich prüfen: Standort-LAN sieht keine KI-Ports; Heimnetz erreicht beide;
 gestopptes VPN-Gateway lässt KI-Container nicht ins Internet; jeder Profilwechsel
 startet exakt einen llama-Container; Text, Tool Call, Bild und Sprachausgabe funktionieren.