[Feature]: Provider onboarding: allow editing/adding model IDs, reachable custom mode, and persist a config.yaml template when the test fails

Start with packages/local-runtime-v2/src/service/model-system/catalog/provider-presets/provider-presets.service.ts and packages/tui/src/tui/features/provider/onboarding.ts, tracing preset transport resolution, model selection, saveInput(), and save(). Verify the interactive flow against the listed acceptance criteria, including failed-test persistence and a validated OpenRouter openai-completions fixture.

Product or interface

CLI - interactive TUI

Use case and problem

The interactive "add third-party provider" flow is too rigid for aggregators like OpenRouter, and a failed connectivity test discards everything instead of leaving an editable config template. Concretely:

1. OpenRouter is not offered at all. Presets come from models.dev via packages/local-runtime-v2/src/service/model-system/catalog/provider-presets/provider-presets.service.ts, but resolveTransport() only recognizes @ai-sdk/openai, @ai-sdk/openai-compatible, and @ai-sdk/anthropic. models.dev lists OpenRouter as @openrouter/ai-sdk-provider, so the OpenRouter preset is silently dropped from the picker.

2. Known-provider models are locked to the preset list; only the URL can be edited. In packages/tui/src/tui/features/provider/onboarding.ts, the known-provider flow lists this.template.models, and Ctrl+E edits only the Base URL. saveInput() for a template sends models: this.template.models and modelId: this.selectedModelId. So if a user picks the DeepSeek preset (base URL https://api.deepseek.com, model ID deepseek-flash) and changes the URL to OpenRouter, they cannot change the model ID to deepseek/deepseek-v4.1-flash — the test fails, and there is no model-ID field to fix it. (The generic "Custom provider" entry does let you type a model ID, but it is a separate path and does not carry the preset's base URL/format.)

3. A failed test saves nothing. onboarding.ts save() reports Changes were not saved. ... and returns; no custom_provider entry is written to config.yaml. The only recovery is to quit and hand-edit ~/.minimax/config.yaml.

Net effect: adding OpenRouter requires knowing the models.dev npm quirk, hand-editing YAML, and guessing the custom_provider shape.

Desired behavior

Make the interactive flow flexible enough that a known aggregator/provider can be configured without hand-editing YAML:

• Recognize aggregator presets. Accept @openrouter/ai-sdk-provider (map it to openai-completions), or more generally treat OpenAI-compatible providers as addable.
• Editable model ID in the known-provider flow. Allow adding/editing a model ID (and optionally capability/limit fields) for a selected preset, not just choosing from template.models. A good UX: keep the preset list, but offer "Add model ID..." / an editable field alongside Ctrl+E edit URL.
• Reachable custom mode prefilled from a preset. Entering a model ID manually should be possible without abandoning the preset's base URL and API format.
• Persist on failure. When the connection test fails, still write the provider entry (or a clearly-marked draft/template) to config.yaml and point the user at it, instead of discarding all input. The pre-save docs already say unsaved changes remain in the UI as a draft; persisting a template would make that usable across restarts.

Acceptance criteria:

• Picking OpenRouter (or a provider whose models.dev npm is unknown) is possible from the picker, or results in an editable custom entry rather than a dropped preset.
• From a known-provider entry, a user can change both the Base URL and the model ID before testing.
• After a failed test, the provider appears as an editable entry in config.yaml (or the UI explicitly offers "Save anyway as template").
• A validated example fixture covers an OpenRouter openai-completions provider added through the interactive flow.

Platform

Multiple platforms

Alternatives and additional context

• Workaround today: hand-edit ~/.minimax/config.yaml and add the custom_provider entry directly.
• Related: #215 (generic OpenRouter support), #288 (runtime support for compat.openRouterRouting, which is the other half of OpenRouter support).
• mcode --version: 0.5.1.