fix(dashboard): remap Kimi Code API-key save to admitted managed id (#10096)

[diegosouzapw]

Closes #10096

Root cause

The unified Kimi Code dashboard card's API-key branch posted provider: "kimi-coding" to POST /api/providers. "kimi-coding" is an OAuth-primary managed provider id — it is not an admitted API-key/dual-auth connection id (isManagedProviderConnectionId("kimi-coding") is false), so the backend correctly rejected the create with 400 {"error":"Invalid provider"}, even though the key-validation check passed. The dedicated managed API-key id kimi-coding-apikey is admitted (src/shared/constants/providers/apikey/regional.ts, hiddenFromDashboard: true), which is why the documented workaround (opening /dashboard/providers/kimi-coding-apikey directly) worked.

This is a regression from #7531 (unified Kimi Code card), which folded OAuth + API-key auth under one card but kept the API-key save path posting the OAuth id.

Fix

Added resolveApiKeySaveProviderId() in src/app/(dashboard)/dashboard/providers/[id]/hooks/useApiKeySave.ts to remap the POST payload's provider field to "kimi-coding-apikey" specifically for the API-key save flow, leaving every other provider id untouched. The OAuth flow (handleOAuthSuccess in ProviderDetailPageClient.tsx) does not go through this hook and continues posting "kimi-coding" unchanged (verified no other reference to "kimi-coding" exists in ProviderModalsPanel.tsx outside the OAuth branch at line 242).

This matches the reporter's preferred option 2 (dashboard remap) — lower risk than admitting kimi-coding into DUAL_AUTH_PROVIDER_IDS, and keeps the existing kimi-coding-apikey connection model intact.

Regression test (Hard Rule #18 — TDD)

tests/unit/bug-10096-kimi-coding-apikey-save.test.ts:

• resolveApiKeySaveProviderId("kimi-coding") === "kimi-coding-apikey", and the remapped id is admitted by isManagedProviderConnectionId.
• resolveApiKeySaveProviderId leaves "openai", "kimi-coding-apikey", and "qoder" untouched (no regression for other providers).

node --import tsx/esm --test tests/unit/bug-10096-kimi-coding-apikey-save.test.ts
✔ Kimi Code API-key save flow remaps to the admitted managed API-key id
✔ resolveApiKeySaveProviderId leaves every other provider id untouched
ℹ tests 2 | ℹ pass 2 | ℹ fail 0

Gates run

• npm run typecheck:core — exit 0
• npx eslint --suppressions-location config/quality/eslint-suppressions.json on changed files — exit 0, no findings
• Pre-commit hooks (lint-staged, check-docs-sync, check:any-budget:t11, check:tracked-artifacts) — passed on commit
• Regression test above — pass
• node scripts/check/check-file-size.mjs — no new failures reported for touched files
• Full-repo check-complexity/check-cognitive-complexity/check-test-discovery gates and the full npm run test:unit suite were still running at hand-off time due to extreme host contention from a 13-way parallel session fan-out (load avg >200); the diff is a 2-line pure remap function plus wrapping an existing JSON.stringify payload, so risk to those ratchets is judged negligible, but CI will independently confirm.

⚠️ base-red inherited: #9985 — ESLint errors (2) from #10250 (pre-existing on release/v3.8.50 tip, unrelated to this change)

[diegosouzapw]

Fix requested: the new helper remaps only the single-entry POST in useApiKeySave.ts. The unified Kimi card's bulk tab remains enabled, and AddApiKeyModal.tsx still posts provider: "kimi-coding" directly to /api/providers/bulk. At the PR head, that route rejects the ID because isManagedProviderConnectionId("kimi-coding") is false, while "kimi-coding-apikey" is admitted. Please remap or disable bulk for this card and add a regression test for the chosen path. The focused probe was run outside the PR head, so this finding is marked PLAUSIBLE.