feat: add Apertis to provider migration mapping

[theQuert]

Summary

• Move Apertis from UNSUPPORTED_PROVIDERS to PROVIDER_MAP in the legacy migration mapping
• Add proper field mappings: apertisApiKey, apertisModelId, apertisBaseUrl
• Enables legacy VS Code extension settings to migrate correctly to the new CLI backend

Apertis is an OpenAI-compatible AI gateway at https://api.apertis.ai supporting 470+ models. The original Apertis provider was added in #5247 (VS Code extension). This PR enables the provider in the new architecture.

Test plan

• Verify legacy Apertis settings migrate to new CLI backend format
• Verify Apertis does not appear in UNSUPPORTED_PROVIDERS warnings
• TypeScript type check passes (bun typecheck)

[kilo-code-bot]

Code Review Summary

Status: 1 Issue Found | Recommendation: Address before merge

Overview

Severity	Count
CRITICAL	0
WARNING	1
SUGGESTION	0

Issue Details (click to expand)

No new issues on the current PR diff. The previous apertis warning in packages/kilo-vscode/src/legacy-migration/provider-mapping.ts is resolved.

Other Observations (not in diff)

Issues found in changed files outside the current PR diff and therefore not eligible for inline comments:

File	Line	Issue
packages/ui/src/context/marked.tsx	644	file.path is still written into data-file-path without attribute escaping, so a Windows-style path containing " can break out of the attribute and inject HTML/JS into rendered markdown

Files Reviewed (13 files)

• .vscode/tasks.json
• packages/kilo-vscode/src/DiffViewerProvider.ts
• packages/kilo-vscode/src/KiloProvider.ts
• packages/kilo-vscode/src/extension.ts
• packages/kilo-vscode/src/legacy-migration/provider-mapping.ts
• packages/kilo-vscode/webview-ui/agent-manager/DiffPanel.tsx
• packages/kilo-vscode/webview-ui/agent-manager/FullScreenDiffView.tsx
• packages/kilo-vscode/webview-ui/agent-manager/review-annotations.ts
• packages/kilo-vscode/webview-ui/diff-viewer/DiffViewerApp.tsx
• packages/kilo-vscode/webview-ui/src/components/chat/PromptInput.tsx
• packages/kilo-vscode/webview-ui/src/types/messages.ts
• packages/opencode/src/provider/provider.ts
• packages/ui/src/context/marked.tsx

Fix these issues in Kilo Cloud

---

_{Reviewed by gpt-5.4-20260305 · 1,138,300 tokens}

[markijbema]

Hey @theQuert — the migration mapping looks structurally correct (the legacy field names apertisApiKey, apertisModelId, apertisBaseUrl match what exists in the legacy codebase), but I'm not sure how the end-to-end flow would work.

The migration code writes the API key to the CLI backend's auth store under providerID: "apertis", but there doesn't seem to be an apertis provider defined anywhere in the new CLI:

1. Bundled providers in packages/opencode/src/provider/provider.ts — no Apertis entry in BUNDLED_PROVIDERS or CUSTOM_LOADERS
2. models.dev (https://models.dev/api.json) — no apertis provider listed
3. The Vercel AI SDK has no built-in Apertis provider

So after migration, the API key would be stored in auth but there'd be no provider to consume it — the user would see no Apertis option in the model picker.

Could you elaborate on how you expect this to work? Would this need a companion PR to add Apertis to models.dev? Or should the migration id map to "openai-compatible" instead (since the legacy ApertisHandler is OpenAI-compatible, hitting https://api.apertis.ai)?

[markijbema]

see comment

[theQuert]

@markijbema Thanks for the detailed review! You're right — the migration was storing the API key under providerID: "apertis" but there was no corresponding provider in the CLI backend.

I've added Apertis as a registered provider in the CLI:

1. packages/opencode/src/provider/models.ts — Injects apertis provider in ModelsDev.get() (same pattern as the kilo provider), using @ai-sdk/openai-compatible SDK with https://api.apertis.ai/v1 as base URL
2. packages/opencode/src/provider/model-cache.ts — Adds dynamic model fetching from Apertis /v1/models endpoint (OpenAI-compatible format) with auth resolution from Config → Auth store → env vars (APERTIS_API_KEY)

This means after migration, the stored API key is consumed by the registered apertis provider, and models are fetched dynamically from the API. The migration mapping id: "apertis" now has a matching provider to consume it.

Pushing the changes now.