feat: 3-tier provider credential resolution (env var → .env → stored config)

[TheArchitectit]

Problem

PR #3017 merged setup_wizard.rs which saves provider config (kind, apiKey, baseUrl, model) to ~/.claw/settings.json. However, no provider ever reads that stored config back. The credential resolution path is purely env-var-based:

• AuthSource::from_env_or_saved() — Despite its name, never reads from stored config
• resolve_startup_auth_source() — Discards its OAuth config callback (let _ = load_oauth_config;) and reads only env vars
• OpenAiCompatClient::from_env() — Reads only from env vars
• read_base_url() (both providers) — Reads only from env vars

Result: Users who run the setup wizard see no effect. The wizard is dead code.

Solution

Implement a 3-tier credential resolution chain:

Tier	Source	Priority
1	Environment variable	Highest (immediate override)
2	.env file in current working directory	Medium
3	Stored config in ~/.claw/settings.json	Lowest (fallback)

How it works

read_env_or_config("ANTHROPIC_API_KEY", "anthropic")
  ├── Tier 1: std::env::var("ANTHROPIC_API_KEY")  → found? return it
  ├── Tier 2: dotenv_value("ANTHROPIC_API_KEY")    → found? return it
  └── Tier 3: settings.json provider.apiKey         → kind=="anthropic"? return it

The stored provider kind must match the provider being resolved for — if settings.json has kind: "xai" and we are resolving credentials for the Anthropic provider, tier 3 returns None. This prevents cross-provider credential leakage.

Changes

New types

• RuntimeProviderConfig — struct with kind, api_key, base_url fields parsed from the "provider" JSON object in settings.json
• RuntimeConfig::provider() — accessor for stored provider config
• parse_optional_provider_config() — extracts provider section from merged settings

Updated functions

• AuthSource::from_env_or_saved() — Now actually reads from stored config (tier 3) when env vars are absent. Previously the "or_saved" name was aspirational — the function was identical to from_env().
• resolve_startup_auth_source() — Same 3-tier treatment. No longer discards the OAuth config callback (kept for API compatibility).
• has_auth_from_env_or_saved() — Also checks stored config
• read_base_url() (anthropic.rs) — 3-tier base URL resolution
• read_base_url() (openai_compat.rs) — 3-tier base URL resolution

New functions

• read_env_or_config() (mod.rs) — Core 3-tier credential resolution
• read_base_url_from_config() (mod.rs) — Base URL resolution from stored config
• OpenAiCompatClient::from_env_or_saved() — 3-tier resolution for OpenAI/xAI/DashScope providers (analogous to the Anthropic path)

Tests

3 new tests for RuntimeProviderConfig parsing:

• provider_config_default_is_empty_when_unset — empty settings → all fields None
• provider_config_parses_kind_api_key_and_base_url — full provider section parsed correctly
• provider_config_handles_partial_provider_object — only kind+apiKey, no baseUrl

Diff verification

5 files changed, 349 insertions(+), 5 deletions(-)

All additions, no deletions. No upstream commits are reverted. The diff is feature-only.

Settings.json structure

{
  "provider": {
    "kind": "anthropic",
    "apiKey": "sk-ant-...",
    "baseUrl": "https://api.anthropic.com"
  },
  "model": "sonnet"
}

This is exactly the format that save_user_provider_settings() (already on main from PR #3017) writes.

Testing

# Set up via wizard
claw setup  # or /setup from REPL

# Verify credentials resolve from settings.json (no env vars needed)
unset ANTHROPIC_API_KEY
claw --model sonnet  # should use stored config

# Verify env var still takes priority
export ANTHROPIC_API_KEY=sk-different
claw --model sonnet  # should use env var, not stored config

[1716775457damn]

This makes the setup wizard actually functional — good catch that #3017 saved config but nothing read it. The 3-tier priority (env var → .env → stored) is well thought out, and covering all four providers (Anthropic, OpenAI, xAI, DashScope) with both API key and base URL resolution is thorough.\n\nMinor concern: the rom_env_or_saved naming across multiple provider files could be consolidated into a shared trait or helper to reduce duplication. Also, cargo fmt is failing — a quick cargo fmt --all before merge will fix that.