feat: Audio-Streaming (chunked TTS) über WebSocket (#4 Ausbau)

- SentenceChunker (pipeline/sentence_chunker.py): inkrementelle Satzsegmentierung
- Orchestrator.chat_stream(on_audio): satzweise TTS, Audio-Chunk pro fertigem Satz;
  Gesamtaudio zusaetzlich an den Output-Endpunkt
- WS /ws/chat {"audio_stream":true}: audio-Events (json seq + binaerer Frame) live,
  kein finales Vollaudio; mit stream kombinierbar
- Tests: 45 gruen (+2: Sentence-Chunker, Audio-Streaming)
- Doku aktualisiert (README, BEDIENUNGSANLEITUNG, Architektur)

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

README.md

@@ -133,13 +133,17 @@ der Server streamt strukturierte Events zurück: `ack` → `semantic` → Audio
 Erinnerungen gelten wie bei `POST /api/chat`.
 
 **Token-Streaming:** Mit `{"text": "...", "stream": true}` schickt der Server die
-LLM-Antwort schon während der Generierung als `token`-Events
-(`ack` → `token*` → `semantic` → Audio → `done`) — spürbar geringere wahrgenommene
-Latenz. OpenRouter und der lokale OpenAI-kompatible Provider streamen via SSE;
-Provider ohne Streaming liefern die komplette Antwort als ein `token`-Event.
+LLM-Antwort schon während der Generierung als `token`-Events — spürbar geringere
+wahrgenommene Latenz. OpenRouter und der lokale OpenAI-kompatible Provider streamen
+via SSE; Provider ohne Streaming liefern die komplette Antwort als ein `token`-Event.
 
-> Audio-Streaming (chunked TTS), Audio-Eingang/Streaming-STT, Barge-in und WebRTC
-> sind als nächste Increments vorgesehen (siehe Architektur-Dokument).
+**Audio-Streaming:** Mit `{"text": "...", "audio_stream": true}` wird das Audio
+**satzweise** erzeugt (chunked TTS) und pro fertigem Satz als `audio`-Event (JSON
+mit `seq` + binärer Frame) gesendet — die Ausgabe beginnt, bevor die Antwort fertig
+ist. `stream` und `audio_stream` lassen sich kombinieren.
+
+> Audio-Eingang/Streaming-STT, Barge-in/Turn-Manager und WebRTC sind als nächste
+> Increments vorgesehen (siehe Architektur-Dokument).
 
 ## Authentifizierung