[Documentation] Windows Docker troubleshooting for TTS-ASR connection failures

Summary

On Windows with Docker Desktop, rapid customization can fail with a misleading client-side SQLite error even though the underlying failure is the TTS-to-ASR connection.

Observed symptoms

• Client: `Error invoking remote method 'model/addModel': TypeError: SQLite3 can only bind numbers, strings, bigints, buffers, and null`
• TTS API: `{'code': -1, 'msg': "'NoneType' object has no attribute 'send'"}`
• In some configurations: `file not exists` or `clean_wav failed:format failed`
• Docker Compose may also fail with YAML errors such as `mapping values are not allowed in this context`

Root causes found

1. The `fish-speech-ziming` TTS image uses `duix-avatar-asr:10095` internally, while the Compose service was named `heygem-asr`.
2. The ASR service was missing the Docker network aliases expected by TTS.
3. The active bind mount was `D:\duix_avatar_data\voice\data -> /code/data`, while troubleshooting initially used a different host path.
4. Incorrect YAML indentation can prevent the network aliases from being applied.
5. The SQLite error is secondary: training returns `code: -1`, then the client attempts to persist `voice_id: false`.

Recommended troubleshooting

services:
  heygem-asr:
    networks:
      ai_network:
        aliases:
          - funasr
          - duix-avatar-asr

After validating the Compose file with `docker compose config --quiet`, recreate the containers and verify:

• ASR logs show it is listening on port `10095`
• `duix-avatar-asr` resolves from the TTS container
• TCP and WebSocket connections to `duix-avatar-asr:10095` succeed
• The WAV file exists both on the host and under `/code/data/origin_audio`

The client should only persist the model after the training API returns success; a failed training response should be surfaced directly instead of producing a misleading SQLite binding error.

This issue is intended to document and consolidate the failure mode described in #11 and #66.