`/login` duplicates platform API key into `managed:kimi-code` provider where it always fails — confusing startup error

Problem

When a user runs /login and enters a Kimi Platform API key (platform.kimi.ai / api.moonshot.ai), the CLI writes it to TWO places in config.toml:

1. [providers.moonshot-ai].api_key — where it works correctly
2. [providers."managed:kimi-code"].api_key — which points at https://api.kimi.com/coding/v1, a different realm that only accepts Kimi Code subscription credentials

At startup, the model-list refresh for managed:kimi-code hits api.kimi.com/coding/v1/models with the platform key and gets rejected. The user sees:

Skipped refreshing managed:kimi-code: Kimi Code models endpoint https://api.kimi.com/coding/v1 rejected the API key: The API Key appears to be invalid or may have expired.

This is confusing because:

• The key just worked moments ago in /login
• The error doesn't say which key or which endpoint failed
• The user has no way to know the platform key was duplicated into a wrong provider

Additionally, if the user previously logged in via Kimi Code OAuth, an expired OAuth token stays in ~/.kimi-code/credentials/kimi-code.json forever — never cleaned up or flagged for re-login.

Reproduction

1. Start Kimi Code CLI fresh
2. Run /login, enter a platform.kimi.ai API key
3. See the startup banner with the "rejected the API key" warning

Expected behavior

• /login should only write the key to the matching provider (e.g. moonshot-ai for platform keys, managed:kimi-code for Kimi Code subscription)
• The startup warning should include the provider name that failed, not a generic "the API Key"
• Expired OAuth credentials should be cleaned up or the user prompted to re-authenticate

Environment

• Kimi Code v0.41.0
• Config: ~/.kimi-code/config.toml
• Credentials: ~/.kimi-code/credentials/kimi-code.json

Start by tracing the /login flow and startup model-list refresh, using ~/.kimi-code/config.toml and ~/.kimi-code/credentials/kimi-code.json as the affected persistence points. Verify provider-specific key handling, make the startup warning identify the failed provider, and define how expired OAuth credentials trigger cleanup or re-authentication.