Simplify LLM configuration layer (closes #504)

[0xallam]

Closes #504.

Strips the LLM-config layer to a thin shim over the OpenAI Agents SDK + LiteLLM. No hand-rolled provider tables, no shorthand expansion, no per-provider gating.

What changes

• One key, any provider. LLM_API_KEY is mirrored into the provider-specific env var (DEEPSEEK_API_KEY, ANTHROPIC_API_KEY, TOGETHERAI_API_KEY, ...) via litellm.validate_environment. No local provider→env-var map.
• No litellm/ prefix in user config. StrixProvider (a 5-line MultiProvider subclass) routes any non-OpenAI prefix through LiteLLM. Users type deepseek/deepseek-v4-pro. Old litellm/... configs still work.
• No tool_choice="required". Modern thinking models (Anthropic extended thinking, DeepSeek /beta, Bedrock newer Claude) reject it; convergence relies on _finish_tool_use_behavior + _append_noninteractive_tool_required_message (already in place).
• No bare-name shorthand expansion. Users supply <provider>/<model>. Bare unknown names route to the SDK's OpenAI default; pre-warm-up panel warns when the bare name isn't a known OpenAI model and exits before the doomed call.

Side stability fixes

• Catch the LiteLLM end-of-stream RuntimeError: cannot schedule new futures after shutdown race (background success_handler.submit losing to atexit during interpreter teardown — stream content was already delivered).
• Silence LiteLLM stdout banners via suppress_debug_info, disable_streaming_logging, turn_off_message_logging.
• Dedupe pass also routes via StrixProvider (was stock MultiProvider, broke non-OpenAI configs).
• Bump litellm 1.83.7 → 1.88.0.

[greptile-apps]

Greptile Summary

This PR replaces the hand-rolled LLM configuration layer with a thin StrixProvider subclass of MultiProvider, relying on LiteLLM's own validate_environment for key mirroring and its routing table for provider dispatch. The change eliminates shorthand expansion, per-provider env-var maps, and the universal tool_choice="required" that modern thinking models reject.

• StrixProvider routes any non-openai/litellm/any-llm prefix directly to LiteLLM, so users type anthropic/claude-opus-4-7 instead of litellm/anthropic/claude-opus-4-7; old litellm/… strings continue to work.
• Key mirroring now calls litellm.validate_environment to discover the correct provider-specific env var name instead of uppercasing the prefix, avoiding the TOGETHER_AI_API_KEY / TOGETHERAI_API_KEY class of mismatches flagged in prior review threads.
• Stability fixes include suppressing LiteLLM's stdout banners, catching the ThreadPoolExecutor shutdown race on stream teardown, and routing the dedupe path through StrixProvider (was stock MultiProvider, breaking non-OpenAI configs).

Confidence Score: 5/5

Safe to merge; all changes are well-scoped simplifications with no functional regressions on the main paths.

The core routing change is straightforward and well-tested by the warm-up path. Key mirroring now delegates to litellm's own environment validation rather than a fragile hand-rolled map, fixing the previously flagged provider naming bugs. The two concerns raised are maintenance-oriented: the _supports_responses_custom_tools function uses supports_reasoning as a proxy (a reasonable assumption for current OpenAI models), and the shutdown-race guard matches on a string literal. Neither affects correctness today.

strix/config/models.py — the _supports_responses_custom_tools coupling between supports_reasoning and Responses API capability detection is worth revisiting if new OpenAI models diverge from the current pattern.

Important Files Changed

Filename	Overview
strix/config/models.py	Introduces StrixProvider and _mirror_api_key_to_provider_env; replaces hand-rolled normalisation with litellm.validate_environment. The _supports_responses_custom_tools helper conflates supports_reasoning with Responses API custom tool support.
strix/core/execution.py	Adds LiteLLM shutdown-race guard around the stream event loop; fragile string-matching on RuntimeError message.
strix/core/runner.py	Replaces normalize_model_name with a plain strip() and injects StrixProvider via RunConfig; logic straightforward and consistent with the rest of the change.
strix/interface/main.py	Adds pre-warm-up check for bare non-OpenAI names and exits early with a clear user-facing message; UX guidance updated to use provider/model form.
strix/report/dedupe.py	Switches from MultiProvider+normalize_model_name to StrixProvider, fixing non-OpenAI routing in the dedupe path.
strix/agents/factory.py	Removes reset_tool_choice=interactive; consistent with the universal removal of tool_choice="required" in this PR.
strix/core/inputs.py	Simplifies make_model_settings by dropping the model_supports_reasoning guard; reasoning params are now forwarded unconditionally and silently dropped via drop_params for unsupported models.

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/models.py:125-130
**`supports_reasoning` used as a proxy for Responses API custom tool support**

`_supports_responses_custom_tools` returns `supports_reasoning` from litellm's model cost table, but the two capabilities are distinct. Today the correlation holds (o3/o4-mini have `supports_reasoning=True` and also accept native Responses API capabilities like `Filesystem`/`Shell`), but a new OpenAI model could support one without the other. If that happens, `uses_chat_completions_tool_schema` will silently mis-format tool definitions for the new model, sending Responses-API capability schemas when function-tool schemas are required (or vice versa), causing tool invocation failures at runtime with no obvious error at startup.

### Issue 2 of 2
strix/core/execution.py:359-361
**Fragile substring match on a runtime error message**

Catching `RuntimeError` by checking for `"after shutdown"` in the message string is fragile in two ways: if LiteLLM ever rewords the message (e.g. "cannot schedule new futures after interpreter shutdown"), the race exception will propagate as an unhandled error instead of being silently swallowed; and if some other `RuntimeError` happens to contain "after shutdown", it will be incorrectly suppressed. Consider matching against a specific exception type or a more structured sentinel if LiteLLM exposes one; alternatively, tightening the guard slightly reduces the blast radius.

```suggestion
                except RuntimeError as stream_exc:
                    if not any(
                        phrase in str(stream_exc)
                        for phrase in ("after shutdown", "after interpreter shutdown")
                    ):
                        raise
```

_{Reviews (6): Last reviewed commit: "Use function-tool schema for non-reasoni..." | Re-trigger Greptile}