[Feature] OAuth 2.0 Device Authorization Grant (RFC 8628) for CLI/headless authentication

[clouatre]

Is your feature request related to a problem? Please describe.

CLI tools and headless applications cannot use the current PKCE OAuth flow because it requires an HTTPS callback URL. Users must manually copy-paste API keys from the dashboard, which is error-prone and breaks the developer flow.

I'm building a Rust CLI for OSS contribution triage that needs OpenRouter API access. With the rise of AI-powered CLI tools (Claude Code, Codex, Block Goose, Mistral Vibe, etc.), there's growing demand for seamless CLI authentication without manual token handling.

Describe the solution you'd like

Implement OAuth 2.0 Device Authorization Grant (RFC 8628):

1. CLI calls POST /auth/device/code with client_id and optional scope
2. OpenRouter returns device_code, user_code, verification_uri, expires_in, interval
3. CLI displays: "Visit https://openrouter.ai/device and enter code: XXXX-XXXX"
4. CLI polls POST /auth/device/token with device_code (respecting interval)
5. User authorizes in browser
6. OpenRouter returns access_token and optional refresh_token

Describe alternatives you've considered

• Current PKCE flow: Requires HTTPS callback URL, not suitable for CLI/headless
• Manual API keys: Error-prone, breaks developer flow
• Environment variables: Works but requires users to manage token lifecycle manually

Additional context

Prior art:

• GitHub: https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps#device-flow
• Google: https://developers.google.com/identity/protocols/oauth2/limited-input-device
• AWS CLI: aws sso login --use-device-code

Use cases:

• Third-party Rust/Go/Python CLI tools
• SSH sessions without browser access
• Desktop apps without embedded browser
• Initial authentication for AI coding assistants

Suggested token design (following GitHub's approach):

• Access tokens: Long-lived or configurable expiry
• Scopes: Supported via scope parameter in initial /auth/device/code request
• Refresh tokens: Optional for short-lived token rotation

Related: #31 (OneClickLLM for browser apps - similar UX goal)