Desktop: unavailable ACP runtime is shown as "Could not load live models"

> [!IMPORTANT]
> Do not include security vulnerabilities in a public issue. [Report them
> privately through a GitHub security advisory](https://github.com/block/buzz/security/advisories/new).

**Describe the bug**

When an ACP harness is *already known to be unavailable* (`cli_missing`, `adapter_missing`, `adapter_outdated`, `not_installed`), the Agent defaults / create / edit model UI still shows the generic discovery failure:

> Using built-in model options. Could not load live models for Anthropic.

That sentence is the fallback for a failed *live model catalog* fetch. It points the user at provider credentials / model loading. The backend detector has already returned a more specific availability reason (for example the Claude Code CLI is not installed), and the harness dropdown even suffixes the same row with `(CLI missing)`. The model-status line then contradicts that and looks like a provider/API problem.

This is not “Claude Code live models fail to load when the CLI is present and signed in” (#2581). Here the runtime is unavailable, live discovery is correctly skipped, and the UI *invents* a model-catalog error.

**Steps to reproduce**

1. Use a machine where at least one preset harness is detected as unavailable (example: Claude Code CLI not on the GUI `PATH`, so catalog `availability` is `cli_missing`).
2. Open Desktop → Agent defaults, or Add agent → Create agent / edit a persona that uses that harness.
3. Select the unavailable harness (or leave it as the default when it is already selected).
4. Read the model-field status line.

Code path on `origin/main` (`c3132c3ee982d194cd0198ad07b57ec8bd726e4e`):

1. `usePersonaModelDiscovery` only discovers models when `selectedRuntime?.availability === "available"` (`desktop/src/features/agents/ui/usePersonaModelDiscovery.ts:210-215`).
2. If availability is anything else, it still sets status via (`usePersonaModelDiscovery.ts:249-258`):

```ts
formatModelDiscoveryErrorStatus(
new Error(`Runtime not available: ${selectedRuntimeAvailability}`),
trimmedProvider,
selectedRuntimeLabel,
)
```

3. `formatModelDiscoveryErrorStatus` has handlers for shared-compute, `authentication required`, missing API keys, and Databricks OAuth. `"Runtime not available: cli_missing"` matches none of them, so it falls through to (`personaModelDiscoveryStatus.ts:137-141`):

```ts
`Using built-in model options. Could not load live models for ${providerObjectLabel(provider)}.`
```

4. The same availability enum is already formatted correctly on the harness option itself (`agentConfigOptions.tsx:468-479`: `" (CLI missing)"`, `" (adapter missing)"`, …).

The in-tree unit test currently only asserts that the synthetic error is non-null, not that the message names the availability reason (`agentConfigOptions.test.mjs:225-249`).

**Expected behavior**

If `selectedRuntime.availability !== "available"`, the model status should name that availability and the next action, for example:

- `cli_missing` → this harness’s CLI is missing; install/sign in to the CLI, then reopen
- `not_installed` → this harness is not installed
- `adapter_missing` / `adapter_outdated` → ACP adapter missing or too old

It should **not** say live models could not be loaded for Anthropic/OpenAI/etc.

Do not send the synthetic `Runtime not available: …` string through the model-discovery error formatter. Map the availability enum directly.

**Version and platform**

- Buzz version: `0.5.20` (`desktop/package.json` on `origin/main` `c3132c3ee`)
- OS: macOS (arm64). The formatter is desktop renderer code; same copy on Linux/Windows.

**Logs / additional context**

Related, not duplicates:

- #2581 Claude Code harness shows “Could not load live models for this provider” — about live catalog fetch when Claude Code is the selected harness
- #6662 Create-agent harness dropdown shows every option unavailable when the CLI is only on login-shell PATH — PATH/detection; this issue is the *status copy* after detection has already returned `cli_missing`
- #3934 empty model dropdown when ACP reports `models.availableModels` — different discovery source

The harness row and the model-status line should tell the same story.

Start in desktop/src/features/agents/ui/usePersonaModelDiscovery.ts and personaModelDiscoveryStatus.ts, then compare the availability wording in agentConfigOptions.tsx. Run the relevant tests in agentConfigOptions.test.mjs and verify each unavailable runtime status names its availability reason and next action instead of reporting a live-model loading failure.

Written by the indexing model from the issue text.