fix(*): stop a static read from starting a login

[0xKT]

Summary

Two things a user hits without doing anything unusual.

A static read started a login. Three LiteLLM drivers ship a device-flow
authenticator, and every entry point that resolves a model reaches it. With no
token file on disk, reading a Copilot model's context window printed six GitHub
device codes to stdout and blocked for 410 seconds -- two full three-attempt login
cycles, because the bare and the openrouter-prefixed candidate reach the same
driver. session.create runs that read before the first turn, so the symptom was a
gateway that hung on opening the picker, and the agent loop runs it again every
turn. The cost estimate, which runs after every call, hung the same way through
cost_per_token.

One function now answers whether a model can be handed to LiteLLM at all, and both
lookups consult it. It asks the installed package -- a driver either ships
authenticator.py or it does not -- rather than carrying a list that would need
regenerating on every LiteLLM bump, where a stale copy brings the hang back for
whatever it missed.

The window lookup reads the price table before asking, which covers all 49 rows
those three drivers have between them. The ask stays for everything that cannot
prompt, because it does more than normalize keys: for an openrouter-prefixed
candidate it derives OpenRouter's own numbers, which are in no table row.

Azure OpenAI could be picked and never worked. Its endpoint contains the
tenant's own resource name, so there is nothing to default to, and its client
raises on an empty api_base. The wizard decided who needs an endpoint by name,
matching only the self-hosted entry, and asked Azure for a key alone -- while the
model picker kept its own list of the two providers that need one. The same fact,
answered twice, one answer wrong. It is a registry field now and both read it.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Verification

uv run --all-extras pytest tests/ -q -p no:randomly
  5049 passed, 30 skipped, 13 deselected

uv run ruff check raven/ tests/    All checks passed
bash .claude/scripts/preflight_ci.sh   exit 0

Measured before and after on the paths that hung:

resolve_context_window("github_copilot/gpt-4.1")   410.59s, 6 device codes  ->  128000, 2.06s
estimate_cost_usd("github_copilot/gpt-4.1")        same hang                ->  0.0028, 0.00s

Behaviour parity checked by running the old and new implementations side by side
over the 132 model candidates Raven offers, excluding the four families that would
hang the old one: no context window and no rate differs.

Every test added here was checked by breaking the code it covers and confirming it
fails. Two of those runs found the test rather than the code -- one assertion
passed no field name to the helper it was testing, and one probe raised an
exception the lookup deliberately swallows -- and both were rewritten until the
mutation bit.

• Relevant tests pass locally
• Relevant lint / type checks pass locally
• User-facing docs or screenshots are updated when needed

Risk

A model belonging to one of the three interactive-login drivers, with no row in the
price table, now resolves to no context window instead of eventually returning one
after the login attempts time out. The caller keeps its configured window, which is
what it already does for any unknown model.

Picking Azure OpenAI in the wizard now asks for an endpoint and a deployment name
in addition to the key. Existing Azure sections are untouched.

Rollback is the revert of this branch.

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

Related Issues

#254 -- the same assumption in the vendor step, for providers Raven carries no spec
for. Not fixed here: that one needs somewhere to keep credentials that are not a
single key. Azure had the same shape while being in the curated list, which is the
half fixed here.