feat: Remove OpenRouter OAuth flow, keep API key authentication

What would you like to be added?

Remove the OpenRouter OAuth authentication flow (browser-based PKCE authorization + local callback server) from Qwen Code. Keep OpenRouter as a provider, but switch its authentication method to standard API key input — the same approach used by DeepSeek, MiniMax, Z.ai, and other third-party providers.

The following should be preserved:

• OpenRouter as a provider (base URL, env key, model catalog)
• Automatic model fetching from https://openrouter.ai/api/v1/models
• Recommended model selection logic
• The OpenRouter · model name prefix

The following should be removed:

• openrouterOAuth.ts — the entire OAuth implementation (~700 lines: PKCE, callback HTTP server, port retry, browser open, signal handling, timeout, code exchange)
• openrouterOAuth.test.ts — its test suite
• OAuth-specific branching in useAuth.ts (the only provider with a genuinely different auth flow)
• OAuth-specific branching in useAuth.test.ts and manageModels.test.ts
• The oauth uiGroup category (OpenRouter is the only provider in it)
• Change openRouterProvider.authMethod from 'oauth' to 'api-key'
• Update openRouterProvider.description to reflect API key auth

Why is this needed?

The OAuth flow is incompatible with web terminal / remote development environments

The OpenRouter OAuth flow relies on three assumptions that don't hold outside a local desktop:

1. A browser can be opened — open(authUrl) has no effect in SSH sessions, Codespaces, Web Terminals, or CI environments
2. localhost:3000 is reachable — the callback server binds to localhost on the machine running Qwen Code; when that machine is remote, the browser redirect (on the user's local machine) never reaches it
3. The terminal and browser are on the same machine — the entire PKCE round-trip assumes co-located browser and callback server

Remote development is a real and growing use case for Qwen Code. The OAuth flow silently fails in these environments — users see the auth URL printed but have no way to complete the round-trip.

OpenRouter is the only OAuth provider — the complexity is not amortized

Every other provider (Coding Plan, Token Plan, DeepSeek, MiniMax, Z.ai, iDealAB, Custom) uses API key authentication. OpenRouter is the sole occupant of the oauth uiGroup. The OAuth infrastructure (PKCE generation, HTTP callback server with port retry, browser launch, signal handling, abort coordination, code exchange) exists entirely to serve this one provider.

API key auth is a trivially equivalent alternative

OpenRouter users can obtain an API key from https://openrouter.ai/keys and paste it into the auth dialog — the same 10-second flow every other third-party provider uses. The automatic model catalog fetching (fetchOpenRouterModels) and recommended model selection can continue to work with an API key; they don't depend on OAuth.

Additional context

Files affected

Net LOC reduction

~700 lines of OAuth implementation + ~400 lines of OAuth tests removed. The remaining OpenRouter provider definition shrinks to ~50 lines (provider config + model fetch helpers).