feat(config): accept GROQ_API_KEY for Groq-hosted models

[DanielNg0729]

What

Adds first-class support for running Strix on Groq. GROQ_API_KEY is now accepted as the LLM key alongside LLM_API_KEY / OPENAI_API_KEY, so users can point Strix at Groq's fast inference with their
provider-native key and a groq/<model> model string.

Resolved #656

Why

Groq offers fast, low-cost inference for open models (Llama 3.x, etc.), but there was no documented, first-class way to use it. Strix only looked for LLM_API_KEY / OPENAI_API_KEY, so a user with a GROQ_API_KEY had to fall back to
undocumented workarounds (custom LLM_API_BASE, openai/ model names). This makes Groq work the same way OpenAI already does.

How

Groq models already route correctly through the existing stack — StrixProvider forwards non-OpenAI prefixes to LiteLLM, and _mirror_api_key_to_provider_env copies the configured key into GROQ_API_KEY (verified: litellm.validate_environment("groq/llama-3.3-70b-versatile") reports GROQ_API_KEY as the required key). The only missing piece was accepting the provider-native key, so this change is intentionally minimal:

• strix/config/settings.py — add GROQ_API_KEY to the api_key
AliasChoices. It's listed after LLM_API_KEY / OPENAI_API_KEY, so
  those keep precedence when multiple are set.
• tests/test_config_loader.py — two tests (alias populates the LLM key;
  LLM_API_KEY wins over GROQ_API_KEY) plus GROQ_API_KEY added to the
  env-reset list.
• README.md — document the Groq config in the Configuration section.

Before / After

Before — no supported path; had to improvise:

export STRIX_LLM="openai/llama-3.3-70b-versatile"
export LLM_API_BASE="https://api.groq.com/openai/v1"
export LLM_API_KEY="gsk_..."   # undocumented, loses provider-native handling

[greptile-apps]

Greptile Summary

This PR adds first-class Groq key support for LLM configuration. The main changes are:

• GROQ_API_KEY is accepted as an LLM API key alias.
• Config-loader tests cover the new alias and LLM_API_KEY precedence.
• The README documents STRIX_LLM=groq/... with GROQ_API_KEY.

Confidence Score: 4/5

The changed config path can pick the wrong provider credential.

• OPENAI_API_KEY still wins over GROQ_API_KEY for Groq models.
• A Groq-only environment can also satisfy the generic key field for non-Groq models.
• The tests cover alias precedence for LLM_API_KEY, but not provider-aware key selection.

strix/config/settings.py

Important Files Changed

Filename	Overview
strix/config/settings.py	Adds GROQ_API_KEY to the generic LLM API key aliases, with provider precedence issues when multiple keys or a non-Groq model are present.
tests/test_config_loader.py	Adds cleanup and tests for the new alias, but does not cover cross-provider key selection.
README.md	Documents the Groq environment setup using STRIX_LLM and GROQ_API_KEY.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
strix/config/settings.py:26
**OpenAI Key Overrides Groq**

When `STRIX_LLM` is `groq/...` and the environment contains both an existing `OPENAI_API_KEY` and the new `GROQ_API_KEY`, this alias order selects the OpenAI key for `settings.llm.api_key`. That generic key is then passed into the model defaults, so Groq requests can authenticate with the wrong provider credential and fail even though the Groq key is set.

### Issue 2 of 2
strix/config/settings.py:26
**Groq Key Becomes Generic**

When only `GROQ_API_KEY` is set and the configured model is not Groq, this alias still populates the generic LLM key. The later provider-env mirroring path can then copy the Groq credential into the missing key for the selected provider, such as `OPENAI_API_KEY`, causing non-Groq runs to authenticate with a Groq token instead of reporting that the provider key is missing.

_{Reviews (1): Last reviewed commit: "feat(config): accept GROQ_API_KEY for Gr..." | Re-trigger Greptile}