fix: stop hardcoding MELO_SPEED so the .env override reaches the worker

supervisord.conf passed MELO_DEVICE through as %(ENV_MELO_DEVICE)s but pinned
MELO_SPEED="1.5", so lowering MELO_SPEED in .env had no effect — the worker
always got 1.5. Pass MELO_SPEED through with %(ENV_MELO_SPEED)s and set a
compose default (MELO_SPEED=${MELO_SPEED:-1.5}, same pattern as MELO_DEVICE) so
the supervisord expansion always resolves and an .env value actually changes
the speaking rate. Default rate is unchanged (1.5). melo_worker logs the
resolved speed at startup, so the env->worker path is verifiable.

Verified: _resolve_speed() returns 1.1 for MELO_SPEED=1.1 (1.5 otherwise), and
`MELO_SPEED=1.1 docker compose config` renders MELO_SPEED: "1.1" into the env.

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

docker-compose.yml

@@ -69,6 +69,10 @@ services:
       # MeloTTS on the GPU (cu128 torch baked by docker/setup-melo.sh). CPU synth
       # serialised under load and pushed TTS to 7-8s; GPU does ~0.3s/sentence.
       MELO_DEVICE: ${MELO_DEVICE:-cuda}
+      # Speaking rate for MeloTTS. Set here (with a default) so supervisord's
+      # %(ENV_MELO_SPEED)s passthrough always resolves and an .env override
+      # actually reaches the melo-worker. Lower it (e.g. 1.1) for a calmer pace.
+      MELO_SPEED: ${MELO_SPEED:-1.5}
       # Optional single-language lock for replies (empty = user's own language).
       OUTPUT_LANGUAGE: ${OUTPUT_LANGUAGE:-ko}
       # Drop the pre-loop planner LLM call to cut voice-reply latency on small