Anthropic identity-linked API keys are unusable: no way to send anthropic-workspace-id

An Anthropic API key that authenticates as a user or service account — rather than belonging to a single workspace — is refused unless the request names the workspace it acts in:

```
400 {"type":"error","error":{"type":"invalid_request_error","message":
"anthropic-workspace-id is required when authenticating with an identity-linked API key;
send the id of the workspace this request acts in."}}
```

`AiModelConfig` has nowhere to put a workspace id, so such a key cannot be used at all — adding the model succeeds, and every chat then fails.

This matters more than it might look: the Claude Console now steers key creation toward service accounts, so a deployment set up today is fairly likely to end up with this key type. A workspace-scoped key still works, so the failure is confusing rather than obvious — the key is valid, and the same key works from `curl` once the header is added.

**Repro:** create a service-account key in the Claude Console, add it as an Anthropic model, send any chat message.

**Where a fix would go:** `getModelDirect`'s `anthropic` branch already forwards `headers` to `makeHandle`, so the change is an optional `workspaceId` on `AiModelConfig`, one header, and one input in the model dialog shown only for Anthropic. That lands around 20 lines across three files — over the PR size in CONTRIBUTING.md, so I've filed this rather than a PR. Happy to send one if you'd prefer.

Start with AiModelConfig and the getModelDirect Anthropic branch, then trace how the model dialog collects configuration and how makeHandle receives headers. Add the optional workspace ID input for Anthropic and verify that an identity-linked key can send a chat successfully while workspace-scoped keys continue to work.

Written by the indexing model from the issue text.