Show what each agent can do and whether it is ready before delegation

## Problem

Before delegating work, a Buzz user cannot answer a basic set of questions in one place:

- Which runtime and model will handle the task?
- Is that runtime installed, authenticated, connected, and currently healthy?
- Which capabilities did the runtime actually report?
- Which MCP/tool sources are attached?
- What permission mode is effective?
- When was this information last verified?

Buzz already observes most of this data, but it is split across runtime discovery, managed-agent process state, presence, and encrypted ACP observer frames. The UI exposes fragments of it in Doctor, configuration dialogs, agent rows, and the session transcript. It does not synthesize an agent-level capability/readiness manifest.

That creates delegation surprises. A saved model may not be applied, a runtime may be installed but logged out, an agent may be running but disconnected from the selected community, or a capability may be assumed even though the runtime never reported it.

Current source paths:

- `desktop/src-tauri/src/managed_agents/discovery/runtime_metadata.rs` is the authoritative static runtime catalog.
- `ManagedAgentSummary` and `ManagedAgentRuntimeStatus` carry process and community-pair lifecycle state.
- The encrypted owner-only observer stream already emits `agent_initialized`, including `agentInfo`, protocol version, and `agentCapabilities`.
- `session_config_captured` already carries model/config/mode state.
- `available_commands_update` is parsed for the transcript but not promoted to an agent-level readiness surface.

## Proposed first slice

Add an owner-visible capability and readiness manifest to the agent details surface. Synthesize it from existing authoritative sources rather than maintaining a second vendor matrix in React.

The manifest should show:

- runtime name and version, ACP protocol version, model, and provider;
- installation and authentication readiness;
- process, community connection, presence, and observer-stream health;
- runtime-reported input/output features such as images, audio, and embedded context;
- runtime-reported commands and tool sources;
- available tool descriptors when the runtime reports them, including source, risk class (`read`, `write`, `execute`, `external`, or `unknown`), and availability;
- requested and effective permission mode;
- platform/runtime limitations and explicitly unreported fields;
- the timestamp of the newest source observation used for the manifest.

The UI must distinguish:

- **reported**: the runtime or Buzz-owned source supplied the fact;
- **unavailable**: the source explicitly says the capability is absent;
- **unknown**: the runtime did not report enough information.

Unknown must never be rendered as unsupported or safe.

## Data and trust boundaries

- `KnownAcpRuntime` remains the sole source for static harness capability facts. New static fields begin in Rust and flow through IPC; React must not add a parallel runtime-ID lookup table.
- Live ACP facts come from the existing encrypted, owner-scoped observer stream.
- MCP server names may be surfaced as tool sources. Commands, arguments, environment variables, credentials, private paths, system prompts, tool inputs/results, and raw configuration values must not appear in the manifest.
- A runtime-provided tool without usable risk annotations is `unknown`, not inferred from its name.
- The first slice should not publish a public capability claim on behalf of a remote agent. Remote/shared manifests need an authenticated event contract and expiry semantics before other users can rely on them.

## Why this shape

- It keeps ACP as the execution boundary; Buzz describes the runtime instead of becoming another model/provider router.
- It reuses verified state already collected for spawn, Doctor, model selection, observer diagnostics, and community lifecycle.
- It makes staleness visible through a last-verified timestamp.
- It avoids the most dangerous failure mode: silently turning missing metadata into an optimistic capability or permission claim.

## Acceptance criteria

- [ ] An agent details view presents runtime identity/version, model/provider, ACP protocol, and last verification time.
- [ ] Installation, authentication, process, community connection, presence, and observer health are separately visible.
- [ ] Reported prompt/input features render from the ACP initialize response.
- [ ] Requested and effective permission mode are both visible when they differ.
- [ ] MCP/tool sources render without exposing commands, arguments, environment variables, credentials, prompts, private paths, or tool content.
- [ ] Reported tools carry a source and explicit risk class; missing risk metadata renders as `unknown`.
- [ ] Unreported and explicitly unavailable capabilities are visually and semantically distinct.
- [ ] A stopped or stale agent never displays a fresh/ready claim based only on cached catalog metadata.
- [ ] The manifest updates when a new initialize, session-config, command, or runtime-lifecycle observation arrives.
- [ ] Community switching clears manifest state with the existing observer store reset.
- [ ] Rust/IPC, observer reduction, and Desktop rendering have regression coverage.
- [ ] The full local `just ci` gate passes.

## Non-goals

- Building a second model/provider engine inside Buzz.
- Claiming support that is absent from the ACP/runtime response.
- Exposing secrets or raw tool/session telemetry.
- A public reputation or capability-attestation protocol.
- Remote MCP catalog pinning and approval policy; the manifest should make that future policy visible but does not implement it.
- Fixing the separate approval/auto-allow behavior.

## Related work

- #2282 concerns consuming scoped data grants. This manifest can eventually show such a grant, but it does not implement grant ingestion.
- #2692 concerns a saved model not being applied to Claude Code. This manifest makes configured-versus-observed model state visible but is not a substitute for that fix.
- #2764 proposes a local-provider allowance indicator. This issue is broader: it exposes the actual runtime/readiness/permission evidence used before delegation.

## Verification plan

- Rust tests for manifest-safe projection and redaction from ACP/session data.
- Tests for requested-versus-effective permission mode and unknown fallbacks.
- Observer-store reduction tests for ordering, staleness, and community reset.
- Desktop component tests for healthy, degraded, stopped, and unreported states.
- Full repository `just ci`.