perf(tts): piper in-process mit gecachtem Modell statt Subprozess pro Satz

Profiling zeigte ~2,2 s Fixkosten pro Satz durch Modell-Start (piper-Binary je
Aufruf). Der Provider nutzt jetzt die piper-Python-API: Stimmmodell wird einmal
geladen (lru_cache), Synthese laeuft im Thread. Resampling in-process (audioop,
numpy-Fallback fuer Py3.13) statt ffmpeg-Subprozess. Binary bleibt als Fallback.

Messung (lokales Setup): erster Ton 5,84 s -> 2,66 s, Turn-Ende 9,82 s -> 4,04 s.

- pyproject: piper-tts zum [local]-Extra
- Tests pruefen weiter den Binary-Fallback (erzwingen _PIPER_LIB=False)

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

tests/test_piper_tts.py

@@ -7,10 +7,18 @@ import stat
 
 import pytest
 
+import app.providers.tts.piper as piper_mod
 from app.providers.tts.piper import PiperTTSProvider
 
-# PCM-Nutzlast des Fake-Binaries: gross genug, dass der ffmpeg-Resampler Samples ausgibt
-# (bei sehr kurzen Eingaben puffert er und liefert nichts). 4000 Bytes = 2000 s16le-Samples.
+
+@pytest.fixture(autouse=True)
+def _force_binary_path(monkeypatch):
+    """Diese Tests pruefen den Binary-Fallback (Fake-piper). Ist die piper-Python-Lib
+    installiert, wuerde sonst der In-Process-Pfad das Fake-Modell zu laden versuchen."""
+    monkeypatch.setattr(piper_mod, "_PIPER_LIB", False)
+
+
+# PCM-Nutzlast des Fake-Binaries. 4000 Bytes = 2000 s16le-Samples.
 FAKE_PCM = b"\x01\x02" * 2000