Team deploy discards `agent_command_override`, silently rebinding agents to a different backend

# Team deploy discards `agent_command_override`, silently rebinding agents to a different backend

## Summary

When a team is deployed, the newly-minted agents do not inherit the source agent's `agent_command_override`. Every clone is written with `agent_command_override: null` and falls back to a default `agent_command`, so an agent that was explicitly configured to run one ACP runtime silently starts running a **different** one — while keeping the same persona, display name, avatar, and system prompt.

This is distinct from the duplicate-identity bug (#5360, #3639, fix in #3646). Even once minting is fixed, the override loss is its own defect: it changes *what the agent actually is*, not just how many of them exist. It is also user-invisible, because the GUI shows one entry per persona.

## Environment

- Buzz Desktop **0.5.10** (`Buzz_0.5.10_amd64.deb`)
- Linux (Linux Mint / Ubuntu 24.04 base, kernel 6.14)
- Registry: `~/.local/share/xyz.block.buzz.app/agents/managed-agents.json`

## What happens

A personal agent "Dolomite" was configured to run OpenClaw over ACP via an explicit override:

```json
{
"name": "Dolomite",
"pubkey": "8c14a02d…b231b1",
"agent_command": "/home/user/.local/bin/openclaw-acp-buzz",
"agent_command_override": "/home/user/.local/bin/openclaw-acp-buzz"
}
```

After creating a team and deploying it, three new "Dolomite" agents were minted. All three:

```json
{
"name": "Dolomite",
"pubkey": "03c094e4…4cf7",
"persona_id": "8c14a02d…b231b1",
"team_id": "dae61e39-…",
"agent_command": "codex-acp",
"agent_command_override": null
}
```

The override is gone and the backend changed from `openclaw-acp-buzz` to `codex-acp`.

### Override retention, whole registry

| group | count | with `agent_command_override` |
|---|---|---|
| originals | 10 | **4** |
| team clones | 15 | **0** |

### The fallback is also non-deterministic

Three deploy batches produced *different* `agent_command` values for the same persona:

| persona | original | batch 17:58:58Z | batch 18:00:45Z | batch 18:07:25Z |
|---|---|---|---|---|
| Fizz | `claude-agent-acp` (override) | `buzz-agent` | `buzz-agent` | `claude-agent-acp` |
| Honey | `claude-agent-acp` (override) | `buzz-agent` | `buzz-agent` | `claude-agent-acp` |
| Bumble | `claude-agent-acp` (override) | `buzz-agent` | `buzz-agent` | `claude-agent-acp` |
| Dolomite | `openclaw-acp-buzz` (override) | `codex-acp` | `codex-acp` | `codex-acp` |

So the same input yields three different results, and none match the configured override.

## Why this is hard to diagnose

The GUI shows **one** Dolomite. Its npub resolves to a *clone*, not the configured agent:

```
npub1q0qff…5fq94e
→ 03c094e4…4cf7 (clone, codex-acp)
```

Because clones inherit `persona_id`, name, avatar, and system prompt, they are indistinguishable in the UI from the agent the user configured. The only way to tell which runtime is serving a message is to decode the npub and grep the registry.

In our case the substituted backend (`codex-acp`) had stale credentials, so every turn failed:

```
WARN buzz_acp: agent_returned (application error — pipe intact) agent=0 outcome="error"
pid=66889 error=Agent reported error (code -32000): Authentication required
WARN buzz_acp::queue: requeueing failed batch with backoff attempt=10 max=10
ERROR buzz_acp::queue: dead-lettering batch after 10 retries — discarding 1 events
```

The configured OpenClaw agent was healthy the entire time and never received the traffic. Time lost was spent debugging OpenClaw, which was never in the path.

## Secondary symptom: the mis-bound clones cannot be removed through the UI

Deleting the team is blocked by the agents the deploy created:

```
Cannot delete team "dae61e39-…": 15 agent(s) still reference it
(Bumble, Bumble, Bumble, Dolomite, Dolomite, Dolomite, Fizz, Fizz, Fizz,
Greg's Mac Codex, Greg's Mac Codex, Greg's Mac Codex, Honey, Honey, Honey).
Delete or reconfigure them first.
```

The error is correct, but the remedy is not reachable: because every clone shares the source `persona_id`, name, and avatar, the agent list renders one entry per persona and the individual duplicates cannot be selected. `buzz agents` has no local delete either — only `draft-create` / `draft-update` (which open a Desktop form) and relay-side `archive` / `unarchive`. So the deploy can create agents the UI cannot subsequently remove.

The only path we found was to quit Buzz Desktop and remove the `team_id`-matching rows from `managed-agents.json` by hand (25 → 10 entries), after which the team deleted normally. Requiring a hand-edit of app state to undo a deploy seems worth fixing alongside the override loss — ideally the deploy dialog should offer "remove team agents" as part of team deletion.

## Expected behavior

A team-deployed agent should inherit the source agent's runtime configuration — `agent_command_override` at minimum, and by extension `agent_command`, `agent_args`, and `mcp_command`. If an override cannot be carried over, the deploy should fail loudly rather than silently substitute a different runtime.

## Reproduce

1. Create a personal agent and set an explicit `agent_command_override` (any non-default ACP runtime).
2. Add that agent's persona to a team; deploy the team to a channel.
3. Inspect `managed-agents.json`: the minted agent has `agent_command_override: null` and a different `agent_command`.
4. Message the agent in the GUI — traffic goes to the substituted runtime.

## Related

- #5360 — creating a team mints duplicate identities (same root call path)
- #3639 / #3646 — team deploy force-mints instead of reusing; fix open since 2026-07-29
- #4764 — preset harnesses spawn without declared args (incl. `openclaw`)
- #3905 — resolve preset args by command match when no runtime id is set

Reproduce the team deployment with an explicit agent_command_override, then inspect the minted rows in managed-agents.json and trace the team deploy path that creates them. Verify that clones retain agent_command_override and the related runtime configuration, or that deployment fails loudly instead of substituting a backend. Confirm the result by messaging the deployed agent and checking that traffic reaches the configured runtime.

Written by the indexing model from the issue text.