feat(agents): auto-respawn (or inbound-driven wake) for a crashed buzz-acp pair; detection is UI-poll-driven only

### Summary

When a managed agent's buzz-acp child process dies unexpectedly (crash, OOM kill, stray `kill`), the desktop detects it only lazily, via the members-sidebar status poll, and nothing ever restarts it. The agent silently stops answering mentions until the user opens the sidebar (to see it stopped), then clicks Start, or restarts the desktop. For a community agent the failure mode is "went quiet, no signal", which is the worst kind of breakage for something meant to run unattended.

Tested on 0.5.20 (observed live) and re-verified against main at 0.5.23 (3c7f288c6). Environment: Linux, self-hosted relay, `runtime: hermes` (hermes-acp), community-scoped.

### What happens today (verified against main)

- `list_managed_agent_runtimes` (`desktop/src-tauri/src/managed_agents/runtime_commands.rs`, ~line 157) reaps exited children when the members sidebar opens: `try_wait()` detects the exit, receipt removed, session cache cleared, `last_stopped_at` set, status emitted. Good, the zombie no longer lingers invisible like it did on 0.5.20.
- But detection rides entirely on that UI poll. With the sidebar closed, nothing notices. There is no exit-watch task on the child, no periodic sweep toward liveness, and no notification.
- Nothing respawns: `start_pair` runs only on explicit demand (Start button, restart flows, launch reconcile for `start_on_app_launch` agents, inbound persona-config refresh). `auto_restart_on_config_change` covers config edits only; a crashed child is outside its scope.
- The doc comment on `reconcile_managed_agent_runtimes` (runtime_commands.rs ~460) says "an @mention wakes a pair", but I could not find a wake path for a DEAD pair: inbound mention routing depends on the child's own relay subscription, which is exactly what died. If that wake path exists somewhere I missed, this issue reduces to the detection/notification gap; if not, the doc overstates current behavior.

### Repro

1. Start a managed agent (buzz-acp child under the desktop; receipt in `agent-pids/`)
2. `kill -9` the buzz-acp child
3. Leave the members sidebar closed; DM / mention the agent: no reply, no error, no notification
4. Open the members sidebar: agent now shows stopped (0.5.23 behavior; on 0.5.20 it stayed stale)
5. Recovery requires a manual Start

### Suggested directions (happy to take a run at any)

1. Exit-watch: a background task per pair (or a periodic `try_wait` sweep over the runtimes map, independent of the UI poll) that reaps, updates the record, and emits status the moment the child dies
2. Crash-restart: optional record-level flag (or extend the existing auto-restart setting) restarting children that died without an explicit Stop, with capped backoff to avoid crash-loops (the existing `replay_floor` / lifecycle frame plumbing gives a clean respawn seam)
3. Inbound-driven wake: route a liveness check into the mention path so an @mention to a stopped pair respawns it before delivery (matches the "an @mention wakes a pair" contract already documented)

### Related

- #4923 (hermes turns complete but reply never publishes): one of our two observed instances was a dead child nobody noticed
- Observed while validating a Hermes-profile -> snapshot import (#4111 context)

Start in desktop/src-tauri/src/managed_agents/runtime_commands.rs, especially list_managed_agent_runtimes, start_pair, and reconcile_managed_agent_runtimes. Trace the existing child lifecycle and inbound mention path before choosing among exit watching, crash restart, and inbound-driven wake; done should include detection and recovery behavior that no longer depends on the members-sidebar poll.

Written by the indexing model from the issue text.