`jcode run --provider openai-api` fails: credential route applied while MultiProvider is still on OpenRouter

Repro

OPENAI_API_KEY=sk-... jcode run --provider openai-api --model gpt-5.6-luna 'hi'

Actual

Error: Failed to select the credential route for --provider openai-api: Provider OpenRouter does not support OAuth/API-key credential selection

Expected

--provider openai-api should pin the native OpenAI provider in API-key mode (same result as the working --provider openai --model openai-api:gpt-5.6-luna spelling).

Analysis

In src/cli/provider_init.rs (~line 1828), explicit_credential_mode(choice) triggers provider.set_credential_mode(mode) — but at that point the MultiProvider's active provider can still be OpenRouter (e.g. when config.toml sets default_provider to a named openai-compatible profile). MultiProvider::set_credential_mode (crates/jcode-base/src/provider/mod.rs ~1818) dispatches on active_provider() and bails for anything but Claude/OpenAI.

The credential-route choice from --provider openai-api implies the OpenAI provider; it should activate/target the OpenAI provider before (or instead of) applying the mode to whatever provider happens to be active from config defaults.

Workaround

--provider openai --model openai-api:<model> works (the model-prefix route pin takes the correct path).

Found while validating WebSocket Responses transport through a local OpenAI-compatible proxy (JCODE_OPENAI_API_BASE + JCODE_OPENAI_TRANSPORT=websocket), where API-key mode is required for the base override to apply.

Start in src/cli/provider_init.rs around line 1828 and trace explicit_credential_mode(choice), then inspect MultiProvider::set_credential_mode in crates/jcode-base/src/provider/mod.rs around line 1818. Ensure --provider openai-api targets the native OpenAI provider before applying API-key mode, including when config.toml selects an OpenRouter-compatible default; verify the reported command behaves like the working openai model-prefix spelling.