feat: Add XTTS v2 support, refactor Docker/GPU infra, and improve Piper engine

- Add XTTS v2 configuration to .env.example
- Refactor Dockerfile to multi-stage build with CUDA 12.1 support
- Update Makefile with Kokoro and XTTS test environment targets
- Refactor Piper engine (app/engines/piper.py) to use python module execution
- Add comprehensive documentation for Kokoro and XTTS plans
- Add helper scripts and patches for build process

session_resumee.md

@@ -136,3 +136,28 @@ To facilitate pushing and pulling Docker images from a remote registry (e.g., `g
     *   The `down` and `help` targets were updated accordingly.
 
 This allows for flexible deployment, supporting both local development with on-demand building and production-like environments pulling from a registry.
+
+### Debugging "Always the Same Text" Bug
+
+The user reported that the TTS server was not synthesizing the provided text but was always returning audio for a fixed, incorrect text.
+
+1.  **Initial Reproduction Attempt (and "422 Unprocessable Entity" error):**
+    *   Attempted to reproduce the bug by sending different texts via `scripts/tts_client.py`.
+    *   Encountered a `422 Unprocessable Entity` error, which led to debugging model loading.
+    *   **Resolution 1 (Model Loading):** Fixed by correcting the volume mount source in `docker-compose.yml` (`./app/models` to `/models`) and updating paths in `app/engines/piper.py` to absolute `/models/piper/`.
+    *   **Resolution 2 (Startup Race Condition):** Added a startup event handler in `app/main.py` to wait for the models directory to be available, preventing a race condition.
+    *   **Resolution 3 (Client Connection):** Mitigated `ConnectionResetError` from client by adding `time.sleep(1)` before `requests.post` call in `scripts/tts_client.py`, indicating a subtle client-server connection timing issue.
+
+2.  **Debugging the "Always the Same Text" Issue:**
+    *   **Initial Test:** Generated audio for "This is a test with the vctk model." and "This is a completely different sentence to verify the bug."
+    *   **Result:** `cmp` showed the files were different, contradicting the user's report that the text was always the same.
+    *   **User Clarification:** User confirmed that *listening* to the files revealed the same speech output, indicating a deeper issue beyond simple file difference.
+    *   **Investigation of `piper.py`:**
+        *   The original method for passing text to the `piper` executable via `stdin` (`--stdin`) seemed correct.
+        *   Manual testing `echo "text" | piper ...` inside the container proved `piper` executable works correctly with `stdin`.
+        *   **Hypothesis:** The `asyncio.subprocess.communicate(input=...)` call was not reliably passing text to `piper`.
+    *   **Attempted Fix 1 (Explicit stdin write):** Modified `piper.py` to manually write to `process.stdin`, `drain`, and `close`. This led to `ConnectionResetError` (server crash).
+    *   **Attempted Fix 2 (Revert and `--input-file` strategy):** Reverted `piper.py` back to `process.communicate()` (after fixing `cmd` to use `--stdin`). Then, changed strategy to use a temporary file for input (`--input-file`) instead of `stdin`. This also led to `ConnectionResetError`.
+    *   **Persistent Crash:** The server consistently crashed after each attempt to synthesize actual audio. Debugging was hampered by `uvicorn`'s reloader hiding tracebacks, even after disabling it. It became apparent that the crash was very low-level, possibly within the `piper` executable's interaction with the file system or system resources.
+
+3.  **Current Status:** The server still crashes when the `synthesize` method is called to generate real audio. The exact cause of this crash is still unknown, as no Python traceback is being produced in the server logs. Further debugging is required to stabilize the `piper` engine's subprocess execution.