OrcaRouter is in the login catalog but has no ProviderChoice, so it can't be selected explicitly

Start with the ProviderChoice definitions and PROVIDER_CHOICE_LOGIN_PROVIDERS in src/cli/provider_init.rs, then compare OrcaRouter with the other OpenAI-compatible profiles and its catalog entries in crates/jcode-provider-metadata/src/catalog.rs. Run cargo test --test provider_matrix; done means OrcaRouter maps to a ProviderChoice and the provider matrix passes.

Description

802f1fe8c "feat(provider): add OrcaRouter profile" (2026-08-16) added OrcaRouter to the login catalog but not to the ProviderChoice mapping table. choice_for_login_provider("orcarouter") returns None, so OrcaRouter cannot be selected as an explicit provider choice, and provider_matrix fails.

Root cause

ORCAROUTER_LOGIN_PROVIDER is present in:

• crates/jcode-provider-metadata/src/catalog.rs:633 (definition)
• crates/jcode-provider-metadata/src/catalog.rs:1265 (LOGIN_PROVIDERS, 54 entries)

but absent from PROVIDER_CHOICE_LOGIN_PROVIDERS in src/cli/provider_init.rs:209, which is what choice_for_login_provider searches:

pub fn choice_for_login_provider(provider: LoginProviderDescriptor) -> Option<ProviderChoice> {
    PROVIDER_CHOICE_LOGIN_PROVIDERS
        .iter()
        .find(|(choice, candidate)| {
            candidate.id == provider.id && !matches!(choice, ProviderChoice::ClaudeSubprocess)
        })
        .map(|(choice, _)| *choice)
}

There is no ProviderChoice::Orcarouter variant at all.

Diffing the two tables, exactly two of the 54 login providers have no ProviderChoice entry:

• AUTO_IMPORT_LOGIN_PROVIDER — intentional, not a real provider
• ORCAROUTER_LOGIN_PROVIDER — the gap

Impact beyond the test

OrcaRouter is reachable through jcode login but not as an explicit --provider choice, unlike every other OpenAI-compatible profile in the catalog.

Reproduction

At e589cbe5a (v0.86.0):

$ cargo test --test provider_matrix
test result: FAILED. 8 passed; 1 failed; 0 ignored

---- provider_matrix_explicit_compatible_choice_overrides_stale_active_profile_state_space stdout ----
thread '...' panicked at tests/provider_matrix.rs:576:32:
orcarouter should map to a ProviderChoice

The test iterates every OpenAI-compatible login provider and requires each to round-trip to a ProviderChoice; OrcaRouter is the only one that does not.

Also reproduced upstream on the macOS runner in run 35504384040 (Run provider matrix tests). On the Linux runner the step is skipped because the TUI step fails first (#1340).

Suggested fix

Add a ProviderChoice::Orcarouter variant and the corresponding PROVIDER_CHOICE_LOGIN_PROVIDERS entry, matching how the other OpenAI-compatible profiles are wired.

Related: #1339, #1340, #1342.