feat: read API keys from environment variables as a fallback

Summary

Fall back to environment variables for API keys when none is set in config. Small change, removes a real setup step for workshops and keeps keys out of files that get committed.

Research/context only; design still to be done.

Problem

API keys can only come from a config file or llm:set-api-key (BaseHttpProvider.scala:141-146 looks up <provider>_api_key, then generic api_key). There is no environment-variable fallback and no keychain integration.

For workshops this means every participant edits a config file before anything works. It also means keys live in files inside model directories — .gitignore entries for config.txt and config-*.txt were added in #42 precisely because of this.

Prior art

mesa-llm reads os.environ[f"{PROVIDER}_API_KEY"] by convention and calls load_dotenv() at import, so a .env file works with no configuration. Their model string openai/gpt-4o implies OPENAI_API_KEY.

We already have the provider naming convention needed for the same thing — ProviderRegistry.apiKeyConfigKey gives openai_api_key, anthropic_api_key, etc.

Possible direction

Lookup order, first match wins:

1. Runtime command (llm:set-api-key)
2. Config file
3. Environment variable — OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY, OPENROUTER_API_KEY, TOGETHER_API_KEY

Deriving the env var name from the existing descriptor keeps this data-driven — no per-provider code.

Open questions

• Env var naming: uppercase the descriptor's apiKeyConfigKey, or hardcode conventional names per provider? (The conventional names are what users already have set for other tools, which argues for matching them.)
• Should llm:provider-status show where a key came from? Useful for debugging "it works on my machine", but must never print the key itself.
• .env file support, or environment only? NetLogo is launched from Finder as often as from a shell, where the environment may not carry through — worth checking before assuming env vars are reliably visible.

Start by reading BaseHttpProvider.scala:141-146 and ProviderRegistry.apiKeyConfigKey to understand the existing key lookup and provider naming. Resolve the open questions about environment naming, .env support, and status reporting before implementation; done means the fallback behavior and precedence are agreed and documented.