fix(desktop): the Versa Azure setup card no longer writes or offers a deployment

[Broccolito]

Follows per-model Versa deployments (#230), which is now on main together with #238 and #248. This PR was stacked on #230 and has been retargeted to main. Against main, its diff is only the card, the card's test and the setup form.

This fixes the first follow-up #230 lists under known gaps: the onboarding card still writes a Versa deployment, and the setup form still carries dead Azure defaults for versa_azure.

What was wrong

With #230, versa_azure posts each model to its own deployment. A configured VERSA_AZURE_DEPLOYMENT_NAME counts as an override only when the catalog doesn't know the value. In that case it serves every request, whatever model the chat selected (explicit_override). Since the public Azure card's keys stopped steering Versa (#238), it is the only deployment key Versa reads.

InstitutionalSetupCard, the UCSF Versa form in onboarding, had two problems:

• It wrote VERSA_AZURE_DEPLOYMENT_NAME = gpt-5.5-2026-04-24 on every connect. That's a catalog deployment, so after fix(versa_azure): each model posts to its own deployment; an unmapped model is refused before it is sent (F1) #230 the daemon ignores it. The write only left a misleading key in the config.
• Its Advanced panel had a free-text "deployment" box. Any name the catalog doesn't know pinned every model to that one deployment, while the chat kept showing the model it picked. That is the label-only model switch fix(versa_azure): each model posts to its own deployment; an unmapped model is refused before it is sent (F1) #230 fixed, brought back through configuration from a first-run form.

Decision: stop writing the key and remove the box

The alternative was to keep the box and write its value only when it isn't a catalog deployment. I rejected it:

• No value makes the box do what its label says. A catalog value is ignored, because choosing that model in the picker already reaches it. Any other value becomes the pin-every-model override.
• It needs a second copy of the catalog. The renderer would have to hard-code the nine ids in VERSA_AZURE_DEPLOYMENTS, which fix(versa_azure): each model posts to its own deployment; an unmapped model is refused before it is sent (F1) #230 calls "the ONE list", or derive them from known_models. That only works while every model name equals its deployment name. It does in today's map, but nothing guarantees it: the catalog is a list of (model, deployment) pairs precisely so the two can differ. Either way the renderer would redo a judgement the daemon already makes, and the copy would drift.
• The escape hatch is for operators. If UCSF adds a deployment the catalog doesn't list yet, it can still be set as an environment variable or in config.yaml. The daemon honours it and logs at info that an override is in force. The provider's own description already says "endpoint and deployment are pre-configured". fix(versa_azure): each model posts to its own deployment; an unmapped model is refused before it is sent (F1) #230 removed with_unlisted_models() for the same reason: a first-run form shouldn't offer a choice that can only fail or only change the label.

What changes

1. InstitutionalSetupCard.tsx drops the deployment state, the VERSA_AZURE_DEPLOYMENT_NAME upsert and the deployment field. The Advanced label now reads "endpoint, API version". A ⚠ comment at VERSA_AZURE_DEFAULTS explains why, so the box doesn't come back by accident.

2. DefaultProviderSetupForm.tsx loses PROVIDER_KEY_DEFAULTS.versa_azure. The entries were never read:

   • Both readers, loadConfigValues and getPlaceholder, look up a default per declared config key.
   • providerConfigSubmitHandler submits declared keys only.
   • versa_azure declares only VERSA_AZURE_API_KEY, on main as well as on fix(versa_azure): each model posts to its own deployment; an unmapped model is refused before it is sent (F1) #230, so the three AZURE_OPENAI_* entries could never apply.

   A comment beside the table now states that rule. The Bedrock namespace split (fix(versa_bedrock): Versa Bedrock and the public Amazon Bedrock card stop steering each other #248) deleted the neighbouring versa_bedrock entry for the same reason, so the comment names both providers.

3. InstitutionalSetupCard.test.tsx: see Tests below.

What stays the same

• The key, endpoint and API version writes are unchanged: same keys, defaults, trimming and order. None of the public AZURE_OPENAI_* keys is written.
• The Bedrock tab is untouched.
• A deployment an earlier connect saved is left in place. The card doesn't delete the key: the old default is a catalog value and inert, and any other value may be an operator's deliberate override. One side effect: reconnecting through the card no longer resets such an override to gpt-5.5, which it used to do on every connect.

Why this had to wait for #230

Before #230, from_env fell back to gpt-5.5-2026-04-24 when the key was unset, so dropping the write alone would have changed nothing. Removing the box would have: on those builds, the box was the only way to make a model other than gpt-5.5 actually answer. #230 is merged, so that ordering now holds.

Tests

The Azure tests in InstitutionalSetupCard.test.tsx go from 2 to 5. The file's two Bedrock tests came from #248 and are unchanged.

• Kept: a connect never writes the public AZURE_OPENAI_* keys. The helper now waits for onSuccess, so the test also sees the writes that happen after checkProvider.
• New: a connect never writes VERSA_AZURE_DEPLOYMENT_NAME.
• Updated: a connect makes exactly these writes, in order: API key, endpoint, API version, BIOROUTER_PROVIDER. This replaces the test that asserted the deployment write.
• New: an endpoint and API version typed into Advanced are written, trimmed. This guards the wiring of the two fields that remain.
• New: Advanced shows the endpoint and API version, and "deployment" appears in neither a field nor the label.

Fail-before check. Run against the unmodified card, the 3 new and updated assertions fail for the intended reasons: the gpt-5.5 write, and two "deployment" matches (the label and the field). The two regression guards pass. After the fix, all 5 pass.

Gate	Result
npm run test:run -- InstitutionalSetupCard	5 passed
npm run test:run (full suite)	442 files; 4,972 passed, 1 skipped
npm run lint:check	pass: typecheck, ESLint, themes, 332 contrast assertions, tokens
npm run format:check	exits 1, on 4 files this PR does not touch, byte-identical to main: contexts.test.ts, toasts.autoClose.test.ts, catalogSubscription.test.ts, workdirOutsideHome.test.ts. All 3 files this PR touches pass.

Updates since the first push.

• fix(versa_azure): the public Azure OpenAI card's keys no longer steer Versa #238 and fix(versa_bedrock): Versa Bedrock and the public Amazon Bedrock card stop steering each other #248 landed on the old base. The two conflicts were unions: each side deleted a different dead defaults entry, and each added a different test helper.
• The stack reached main. Merging main was clean, because main had not touched these three files since the stack's merge-base.

Re-run after each merge: the onboarding and provider-settings vitests (9 files, 104 passed, including all 7 card tests), npm run lint:check, and Prettier on the 3 changed files all pass.

I didn't check this in the running app. The change removes one field from a vertical stack and one word from a label, and the DOM assertions above cover both.

🤖 Generated with Claude Code