Fix ElevenLabs websocket context id handling

[flynn-hamming]

Summary

Fix ElevenLabs multi-context websocket handling so the TTS plugin accepts both contextId and context_id response fields.

ElevenLabs' multi-context websocket API uses snake_case context_id in client messages, and current websocket responses can also include context_id. The plugin only reads camelCase contextId, so valid audio/final messages can be treated as unexpected messages when the response uses snake_case. In LiveKit fallback setups, this can cause ElevenLabs audio to be skipped and a fallback TTS provider to be used instead.

This change keeps existing contextId handling, adds context_id compatibility, and treats flush_done messages for inactive contexts as harmless lifecycle messages.

Tests

uv run ruff format livekit-plugins/livekit-plugins-elevenlabs/livekit/plugins/elevenlabs/tts.py tests/test_plugin_elevenlabs_tts.py
uv run ruff check livekit-plugins/livekit-plugins-elevenlabs/livekit/plugins/elevenlabs/tts.py tests/test_plugin_elevenlabs_tts.py
uv run pytest tests/test_plugin_elevenlabs_tts.py

Result:

10 passed

[CLAassistant]

All committers have signed the CLA.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.

[flynn-hamming]

Hey folks, quick bit of context on why I opened this.

We hit this while testing ElevenLabs streaming voices in a production-ish voice-agent flow. ElevenLabs was sending websocket messages with context_id, but the plugin only looked for contextId, so valid audio messages were getting treated as unexpected and our app fell back to the next TTS provider.

The change is intentionally tiny: keep supporting contextId, also accept context_id, and ignore harmless flush_done lifecycle messages for contexts that are already closed.

Happy to tweak the shape/tests if there is a preferred LiveKit style here. Thanks!