MiniMax OAuth sign-in (subscription-plan auth) alongside the API-key route

MiniMax is a first-class provider kind (`ProviderKind::Minimax` + `MinimaxAnthropic`, crates/config/src/provider_kind.rs:104-111) but its credential path is API-key only (crates/config/src/provider.rs ~419: "Create a MiniMax API key or subscription-plan key in the user center"). MiniMax subscription-plan (Coding Plan) users in other harnesses sign in with OAuth rather than juggling interface keys — add the same path here.

Precedent in-tree: `OpenaiCodex` is OAuth-only (`codewhale auth chatgpt`, Codewhale-owned tokens); `Xai` is `ApiKeyOrOAuth` via Codewhale's native device login. `CredentialAcquisition::ApiKeyOrOAuth` already exists, so the work is the flow, not the model:

- Wire MiniMax's OAuth/device flow for the subscription plan (verify the current endpoints/scopes against MiniMax's docs before implementing — do not guess URLs).
- `CredentialHelp` for `Minimax`/`MinimaxAnthropic` becomes `ApiKeyOrOAuth` with sign-in guidance.
- Tokens stored through the existing credential store with provider scoping; never log them.
- The API-key route keeps working unchanged.

Related: #6157 (MCP OAuth iss fix — same token-handling conventions apply).

Start with crates/config/src/provider_kind.rs and crates/config/src/provider.rs, then inspect the existing OpenaiCodex and Xai authentication flows and verify MiniMax’s current OAuth endpoints and scopes in its documentation. Done means subscription-plan sign-in stores provider-scoped tokens without logging them, CredentialHelp supports ApiKeyOrOAuth for both MiniMax variants, and the existing API-key route still works.

Written by the indexing model from the issue text.