An agent's runtime can die silently — no signal in the channel, no way to restart it

## What happened

Three managed agents (Fizz, Honey, Bumble) run in one channel on Buzz Desktop. After a burst of
`-32603 Internal error` responses across all three, two recovered and one did not. The one that
didn't produced **nothing at all** for the next twelve hours — no reply, no error frame, no status
change — across four separate `@mention` triggers from both a human and another agent.

From inside the channel this is indistinguishable from an agent that is simply slow to answer. The
owner's only clue was asking a second agent to investigate.

The cause turned out to be simple: **its supervisor process was gone.**

```
$ ps -eo pid,etime,command | grep MacOS/buzz-acp
57086 02:40:21 /Applications/Buzz.app/Contents/MacOS/buzz-acp # Honey
57585 02:40:05 /Applications/Buzz.app/Contents/MacOS/buzz-acp # Fizz
```

Two supervisors for three agents. Nothing was subscribed to the third agent's mentions, so its
triggers went nowhere and nothing reported that they had.

## The two gaps

**1. No liveness signal.** A dead agent and a thinking agent look identical in the channel. There's
no heartbeat, no presence transition, and no "your agent stopped" notice — `buzz users presence`
returned a record for the running agent and nothing for the dead one, which is suggestive but not
something the app surfaces to the owner.

**2. No lifecycle control.** `buzz agents` exposes `draft-create`, `draft-update`, `archive` and
`unarchive`. The last two are NIP-IA identity operations — they retire a pubkey, not a process.
There is no start / stop / restart / ping anywhere in the CLI, so neither the owner nor a
coordinating agent can recover a dead runtime without restarting the whole desktop app.

The second gap matters more in multi-agent channels: an agent asked to coordinate others has no
mechanism to notice or repair a peer that has stopped, which is exactly when coordination is needed.

## Suggested shape

Not attached to any particular design, but the smallest useful version looks like:

- **Supervisor restarts a dead agent process**, or at minimum records that it died.
- **A visible signal** when an agent's runtime is down — presence state, a channel notice, or both —
so the owner learns it from the app rather than from asking another agent.
- **`buzz agents status` / `restart `** (owner-scoped) so recovery doesn't require restarting
every agent on the machine.

Happy to send a PR for any of these if maintainers have a preferred shape — say which and I'll build
against it.

*Reported from a real three-agent session; process listing and CLI surface above are verbatim from
that machine.*