Remove Bifrost virtual key from the provider settings form

[TheGreatAxios]

Summary

• Removes the Bifrost virtual key toggle from the agent-modal provider form
• Operators can no longer configure x-bf-vk through the settings UI
• Existing runtime handling for already-stored configs is left intact

Test plan

• Open Ctrl+A provider form — Bifrost field is gone
• Add/edit a provider still works (name, URL, keyless, models)
• Existing providers with bifrostVirtualKey in settings still load without crash

Closes CL-5344

[linear-code]

CL-5344

[TheGreatAxios]

Code review (parent — multi-agent fleet unavailable)

Verdict: approve for UI removal; one follow-up scope note.

Correctness

• Bifrost field removed from form type, labels, hints, validation, keyboard, and render path.
• Test fixture no longer requires bifrostVirtualKey.
• Existing stored bifrostVirtualKey on providers is still typed on AgentProvider and ignored by the form — fail-open for old configs.

Gaps vs issue outcome

• Issue also says “no Bifrost-related config keys required or documented for normal use.” This PR only strips the settings form. Runtime still accepts/stores the flag elsewhere — intentional minimal slice; open a follow-up if product wants full schema/docs purge.

Tests

• Fixture cast cleanup is good; no new behavioral tests needed for a pure field removal.

[TheGreatAxios]

Review — request changes

UI removal of the Bifrost toggle looks complete, but editing an existing Bifrost provider and saving will silently drop bifrostVirtualKey, which contradicts the PR claim that stored configs keep working.

Verdict: request changes

Blocking correctness issue

validateProviderForm no longer emits bifrostVirtualKey, and buildProviderEntry only copies the flag when the submission sets it:

// src/config/providers.ts
...(submission.bifrostVirtualKey === true ? { bifrostVirtualKey: true } : {}),

It preserves apiKey from the existing entry, but not bifrostVirtualKey. So:

1. Provider has bifrostVirtualKey: true in settings → runtime OK.
2. Operator opens Ctrl+A → Edit → changes models/URL/name → Save.
3. Flag is rewritten off → x-bf-vk path stops applying without an obvious error.

That is a silent auth/routing regression for any Bifrost provider that is later edited.

Suggested fix (pick one)

1. Prefer preserve-on-edit in buildProviderEntry: when updating an existing entry, keep existing.bifrostVirtualKey unless the submission explicitly sets it (mirrors apiKey preservation), or
2. In validateProviderForm / submitForm, pass through the original provider’s bifrostVirtualKey when editing.

Also add a unit test: edit a provider with bifrostVirtualKey: true and assert the flag survives a models-only save.

Non-blocking

• Form field / label / hint / toggle key-handler removal looks clean.
• AgentProvider / toAgentProviders still surface the flag for list/runtime projection — good.
• No merge conflict risk (CLEAN, ahead of main).

Test gaps

• Existing tests only assert the form no longer requires the field; nothing covers edit-preserve behavior.

[TheGreatAxios]

Addressed multi-agent review:

• buildProviderEntry now preserves existing.bifrostVirtualKey on edit so re-saving a provider without the removed form field does not drop x-bf-vk routing.

[TheGreatAxios]

Multi-agent review (blended: cto / greybeard / neckbeard / critique / bruckheimer)

Verdict: Approve (after earlier post-review fix)

Fixed earlier

• buildProviderEntry preserves existing bifrostVirtualKey on edit so re-saving without the removed form field does not drop x-bf-vk routing.

Remaining

• Schema still accepts the field for back-compat (intentional).

Ready for human review/merge.

[TheGreatAxios]

Hard review (greybeard + CTO)

Verdict: APPROVE

Greybeard

UI field removed; persistence of existing bifrostVirtualKey retained so we do not clobber stored config. Correct deprecation shape.

CTO

Dead feature off the form without a migration fire drill. Good.

No blockers.