(cartesia stt): expose ink-2 turn-detection thresholds and keyterm params

[ajayarora1235]

Sibling of #6587 (same pattern for xAI STT): exposes the turn-detection tuning parameters documented for Cartesia's /stt/turns/websocket (https://docs.cartesia.ai/api-reference/stt/turns/websocket) on cartesia.STT:

• turn_start_threshold (0.5–0.9, default 0.8) — likelihood above which a turn starts
• turn_eager_end_threshold (0.3–0.6, default 0.4) — likelihood below which turn.eager_end fires
• turn_end_threshold (0.05–0.5, default 0.2) — likelihood below which the turn ends
• turn_end_timeout_ms (640–11200, default 5600) — silence backstop for ending a turn
• keyterm (list, up to 100 terms / 1200 chars) — recall biasing; sent as repeated query params, so the turns-websocket params dict became a list of pairs

These are the primary tuning levers when running ink-2 with turn_detection="stt" in an AgentSession — today the plugin connects to the turns endpoint with no way to adjust them. All five are NotGivenOr and omitted when unset, so the default connection sends the identical query string as before. Passing any of them with a non-turn-detecting model (ink-whisper → the legacy endpoint) raises ValueError, mirroring the model-gated params in the AssemblyAI plugin.

Live-verified against wss://api.cartesia.ai/stt/turns/websocket (real key, today):

• in-range values (e.g. turn_start_threshold=0.85, repeated keyterm) → {"type":"connected", ...}
• out-of-range (turn_start_threshold=2.0) → error frame "turn_start_threshold must be between 0.5 and 0.9." + close — so the server parses and validates exactly these param names (unknown params are silently ignored, which is why the client-side ValueError guard is worth having)

Verified with ruff check / ruff format.

🤖 Generated with Claude Code

[devin-ai-integration]

✅ Devin Review: No Issues Found

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

[tinalenguyen]

thank you for the PR!