fix(stt): read Groq model from stt.groq.model config before env fallback

[liuhao1024]

What does this PR do?

Fixes the Groq STT provider's model resolution to read from stt.groq.model in config.yaml before falling back to the STT_GROQ_MODEL env var / default. Every other STT provider (OpenAI, Mistral, ElevenLabs, local) already follows this pattern, but the Groq branch skipped the config lookup entirely.

Related Issue

Fixes #58734

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• tools/transcription_tools.py — Add stt_config.get("groq", {}) lookup before DEFAULT_GROQ_STT_MODEL fallback, matching the pattern used by OpenAI/Mistral/ElevenLabs/local providers
• tests/tools/test_transcription_tools.py — Add test_config_groq_model_used regression test verifying stt.groq.model is read from config

How to Test

1. Run python -m pytest tests/tools/test_transcription_tools.py -k groq -xvs — all 24 Groq-related tests should pass
2. Run python -m pytest tests/tools/test_transcription_tools.py -x — full suite (108 tests) should pass
3. Verify the new test specifically: python -m pytest tests/tools/test_transcription_tools.py::TestTranscribeAudioDispatch::test_config_groq_model_used -xvs should pass
4. Manual: set stt.groq.model: whisper-large-v3 in config.yaml (without setting STT_GROQ_MODEL env), trigger voice transcription, and confirm Groq uses whisper-large-v3 instead of the default whisper-large-v3-turbo

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.4.1

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A (this is a config resolution fix with no platform-specific behavior)
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

[teknium1]

Thanks for the focused regression fix. The premise still holds on current main: tools/transcription_tools.py:1761-1763 bypasses stt.groq.model and falls straight back to DEFAULT_GROQ_STT_MODEL.

Problems

• The new stt_config.get("groq", {}) can return None for valid YAML stt.groq: null, so the subsequent .get("model", ...) would raise. Current sibling branches use .get("<provider>") or {} after the null-subsection hardening in 3a394210.
• This changes a user-facing configuration contract, but website/docs/user-guide/configuration.md:1627-1634 still describes Groq model overrides as environment-driven only.

Suggested changes

• Use groq_cfg = stt_config.get("groq") or {} and cover a null subsection in the regression tests.
• Document stt.groq.model and its precedence over STT_GROQ_MODEL.

Automated hermes-sweeper review.

[teknium1]

stt.groq: null is valid YAML and makes this expression return None, so the next groq_cfg.get(...) raises AttributeError. Please match the null-safe sibling-provider pattern introduced in 3a394210: stt_config.get("groq") or {}, with a regression test for the null subsection.

[teknium1]

Closing as superseded: this exact fix landed on main via a10bd49ddd (PR #73067) — Groq STT now resolves model or stt.groq.model (config) or DEFAULT_GROQ_STT_MODEL in transcription_tools.py.

Thanks @liuhao1024 — your patch identified the right resolution order; the merged change matches it.