Auth probe for the `claude` runtime reads a different credential store than the ACP adapter, and disagrees in both directions

**Describe the bug**

The desktop probes the `claude` runtime's auth with `claude auth status` (`desktop/src-tauri/src/managed_agents/discovery.rs`, `auth_probe_args`). That command consults the `claude` CLI's own credential store. The runtime Buzz actually spawns is `claude-agent-acp`, which carries its own `claude.exe` inside `@anthropic-ai/claude-agent-sdk-*` and reads `~/.claude/.credentials.json` plus `CLAUDE_CODE_OAUTH_TOKEN`.

Because they consult different sources, the probe does not predict whether the runtime works — and it can be wrong in either direction. Both were observed on the same machine on the same day:

| | `claude auth status` | Real ACP cycle against `claude-agent-acp` |
|---|---|---|
| morning | `{"loggedIn": true, "authMethod": "claude.ai", "subscriptionType": "pro"}`, exit 0 | fails: `Failed to authenticate: OAuth session expired and could not be refreshed` |
| evening | `{"loggedIn": false, "authMethod": "none"}`, exit 1 | works: `stopReason: end_turn` |

Throughout, `~/.claude/.credentials.json` stayed an empty husk — `accessToken` length 0, `refreshToken` length 0, `expiresAt` 0 — regardless of what the CLI reported. The runtime only started working once `CLAUDE_CODE_OAUTH_TOKEN` was set via `claude setup-token`, and at that point the CLI reports "not logged in".

The false-positive direction is the damaging one: the UI shows the runtime as authenticated, the agent starts, joins a channel, and then silently fails every turn.

**Steps to reproduce**

1. Install the Claude Code CLI and the ACP adapter: `npm install -g @agentclientprotocol/claude-agent-acp`.
2. Run `claude auth status` and note the result.
3. Drive the adapter directly over stdio: `initialize` → `session/new` → `session/prompt`.
4. Compare. On a machine where `~/.claude/.credentials.json` is empty but the CLI's own store is populated, step 2 reports authenticated while step 3 fails with `authentication_failed`.

**Expected behavior**

The auth badge reflects whether the runtime Buzz will spawn can authenticate.

**Version and platform**

- Buzz version: 0.5.5 (packaged Windows release)
- `@agentclientprotocol/claude-agent-acp`: 0.65.0
- OS: Windows 11

**Suggested fix**

Probe the consumer, not a sibling: run the adapter's own `initialize` (optionally `session/new`) and treat a successful handshake as authenticated. That exercises the same credential resolution the real turn will use. A cheaper partial improvement would be to also accept `CLAUDE_CODE_OAUTH_TOKEN` being set as evidence, since today its presence is invisible to the probe.

Start in desktop/src-tauri/src/managed_agents/discovery.rs at auth_probe_args, then reproduce the adapter over stdio with initialize, session/new, and session/prompt. Compare the probe result with the real claude-agent-acp authentication path and verify that the UI badge reflects whether the spawned runtime can authenticate, including CLAUDE_CODE_OAUTH_TOKEN cases.

Written by the indexing model from the issue text.