Should managed agents be able to auto-publish their final ACP reply? (per-agent opt-in)

## Summary

Should a managed agent be able to publish its own final ACP reply for a completed turn, as a per-agent opt-in?

Today a managed agent completes a turn and its final assistant text is not published to the channel on its own. We run a 12-agent desk against a self-hosted relay, and the gap means an operator has to go looking for each result rather than seeing it where the conversation is.

We have a working implementation and would rather converge on yours than carry a fork. Happy to close this if the answer is "no" or "not that shape".

## What we built

A per-agent opt-in, honouring what `desktop/src/features/agents/AGENTS.md` already says about this area (no process-global switch, no implicit enabling of existing agents, and the setting participates in the effective spawn config so a running instance is marked for restart):

- `BUZZ_ACP_AUTO_REPLY=true` in an agent's effective environment authorises the harness to publish one final reply per completed single-trigger turn. Any other value leaves it off (fail-closed).
- `set_managed_agent_auto_reply` Tauri command, mirroring `set_managed_agent_auto_restart`.
- A `Switch` on the agent card in `UnifiedAgentsSection`, beside `RestartDiffBadge`.
- `SpawnConfigSnapshot` stores the canonicalised boolean rather than the raw string, so `"false"` and absent are indistinguishable and toggling off does not raise a phantom "Restart required".

Verified live on a 12-agent desk: records → process env → harness config (`auto_reply=true` in the startup line) → an attributable reply published under the agent's own pubkey.

## Design questions we would rather you answer than guess

1. **Per-agent, or per-channel?** We chose per-agent because that is what rule 12 describes. Per-channel would be a different shape and would change the storage.
2. **Where should the opt-in live?** We put it in the agent's `env_vars`, which turned out to be a mistake: `AgentInstanceEditDialog` owns that map and saves it wholesale, so any unrelated agent edit silently clears the flag. A dedicated record field alongside `auto_restart_on_config_change` avoids that. If you want this feature at all, we would follow whichever you prefer.
3. **Is the harness the right layer?** We considered doing this as an MCP lifecycle hook per `docs/MCP_DRIVEN_HOOKS.md`, but publishing as the agent needs the app's relay identity, which a hook does not have. If there is an intended extension point we missed, we would rather use it.

## Offer

If this is wanted, we will open a PR against current `main`. If not, we will close this and stop carrying it — either answer is more useful to us than the current state.

Start by reading desktop/src/features/agents/AGENTS.md, then inspect AgentInstanceEditDialog, set_managed_agent_auto_restart, UnifiedAgentsSection, RestartDiffBadge, SpawnConfigSnapshot, and docs/MCP_DRIVEN_HOOKS.md. Resolve the per-agent storage and harness extension point before implementation; done means a fail-closed opt-in publishes one attributable final reply per completed single-trigger turn without affecting existing agents or producing phantom restart changes.

Written by the indexing model from the issue text.