v0.9.1: add first-class Kimi OAuth device login and token lifecycle

[Hmbown]

Summary

Add a first-class OAuth/device-login path for Moonshot AI Kimi, separate from the existing API-key configuration. This complements #4387 (Kimi K3 model support) but covers account authentication and its lifecycle.

Scope

• Offer Kimi/Moonshot OAuth as an explicit provider-auth option in the CLI and TUI, alongside API-key setup.
• Start the documented device authorization flow, show the verification URL and user code, and make expiry/cancellation states clear.
• Poll with provider-compliant backoff, handle authorization pending/declined/expired responses, and never expose raw parsing failures as the primary user-facing error.
• Store refreshable credentials through the existing secure credential store; refresh access tokens before expiry and provide a reliable logout/clear path.
• Show current authentication state, selected account/provider, and a concrete retry action in provider diagnostics and the model picker.
• Keep OAuth tokens and authorization responses out of logs, transcripts, crash reports, and exported session state.

Upstream access dependency

The current public MoonshotAI/kimi-code implementation uses:

• https://auth.kimi.com/api/oauth/device_authorization and /api/oauth/token
• a fixed registered OAuth client ID
• X-Msh-Platform: kimi_code_cli plus device identity headers

The public repository contains the client implementation but no third-party client/platform registration or allowlist. Codewhale must not impersonate kimi_code_cli merely to pass an upstream coding-agent check.

Before calling this integration complete:

• confirm with the Kimi Code maintainers whether Codewhale should receive its own OAuth client ID and X-Msh-Platform value, or whether the published client ID is intentionally reusable by third-party coding agents;
• if registration is represented in public code, prepare an upstream PR adding Codewhale with the exact product identity and callback/device-flow requirements;
• otherwise file a focused upstream request with the Kimi team for the necessary server-side registration/allowlist and link it here;
• keep the local implementation mock-testable while upstream access is pending, but do not advertise it as working until a real Codewhale-identified device flow and model request succeed.

Acceptance criteria

• A user can complete a Kimi device-login flow without manually copying an API key.
• Interrupted, expired, rejected, malformed, and network-failed flows show actionable guidance and can be safely retried.
• Restarted sessions restore valid credentials or ask for login again when refresh fails.
• API-key users retain their current behavior and can switch authentication modes deliberately.
• Unit/integration tests cover device-code acquisition, polling/backoff, refresh, logout, secure persistence boundaries, and secret redaction with mocked provider responses.
• Real-account smoke evidence is recorded without committing credentials.
• The smoke uses an honest Codewhale product/platform identity; no kimi_code_cli spoofing.
• The linked upstream PR/request or maintainer confirmation records the supported client-ID and platform-registration contract.

[Hmbown]

Upstream investigation started against MoonshotAI/kimi-code at 373abb02f03ef817e2e1937e1cdc4423ef0cd149. The public client hardcodes the registered client ID and X-Msh-Platform: kimi_code_cli; no public third-party registration table is present. The issue now makes honest upstream registration/confirmation a release gate rather than allowing Codewhale to spoof the official CLI identity.

[Hmbown]

Upstream evidence sharpens this dependency:

• Kimi's current third-party-agent documentation supports external coding agents through a Kimi Code API key, and explicitly says clients must preserve their real identity rather than changing the User-Agent: https://www.kimi.com/code/docs/en/third-party-tools/other-coding-agents
• kimi-code (managed OAuth) rejected with 403 access_terminated while kimi-cli works — X-Msh-Platform: kimi_code_cli not on server allowlist MoonshotAI/kimi-code#636 independently reproduces the managed-service gate as a server-side X-Msh-Platform allowlist. Even Kimi's own new kimi_code_cli identity was rejected while the legacy kimi_cli identity worked: kimi-code (managed OAuth) rejected with 403 access_terminated while kimi-cli works — X-Msh-Platform: kimi_code_cli not on server allowlist MoonshotAI/kimi-code#636

So a PR that only changes the public Kimi client cannot grant Codewhale OAuth access. The upstream action is now: ask Moonshot whether third-party RFC 8628 clients are supported; if yes, request a registered client/platform contract for honest codewhale identity; if no, record that OAuth is official-client-only and keep the supported Kimi Code API-key path as the public integration. We will not copy or spoof kimi_cli / kimi_code_cli headers.

[Hmbown]

Upstream registration/policy request filed: MoonshotAI/kimi-code#1795

The request asks Moonshot to either provide an honest third-party device-flow contract (client ID, X-Msh-Platform, User-Agent/device headers, scopes, refresh and endpoint rules) or confirm that managed OAuth is first-party-only. It explicitly commits Codewhale not to impersonate kimi_cli / kimi_code_cli.

Until Moonshot confirms that contract, the supported public route remains Kimi Code's documented console API-key flow. The existing compatibility code that reuses Kimi's first-party client/platform identity is not sufficient release evidence and must not be advertised as first-class Codewhale OAuth.