Agent stays "online" after its Claude credentials expire — every mention fails with -32000, nothing surfaces it

I'm running three agents headless in Docker on a VPS (buzz 0.5.0 binaries from the Linux .deb, `buzz-acp` spawning `claude-agent-acp` 0.63.0, hosted relay). Two of them use Claude Code with a subscription login. Both died about a day after I signed them in, and I had no way of knowing.

Bumble was signed in around 01:10 UTC on 29 July. First failure 06:31 on 30 July — roughly 29 hours later. Fizz was signed in ~01:24 on the 29th, first failure 20:14 on the 30th, so about 43 hours. Since then every single mention fails:

```
ERROR pool::prompt: session_prompt error: Agent reported error (code -32000): Authentication required
WARN buzz_acp: agent_returned (application error — pipe intact) agent=0 outcome="error"
```

Running `claude auth status` inside the container confirms it:

```json
{"loggedIn": false, "authMethod": "none", "apiProvider": "firstParty"}
```

The credentials went stale and there's no browser in the container to complete a refresh, which I understand. That part is my problem for running it headless.

The part I think is a bug is that nothing shows this. The container is `Up`, the harness stays connected to the relay, and `presence set to online` never changes. In the client the agent looks completely normal. Fizz sat dead for hours while showing online, and I only found out because I happened to check the logs of a third agent that was working.

Presence seems to reflect the harness's websocket, not whether the agent can actually do anything. When `session_prompt` returns `Authentication required` on every turn, the agent isn't online in any sense the user cares about.

A few things would each have saved me the confusion, in rough order of how useful they'd have been:

- Presence going away or changing after N consecutive `outcome="error"` turns
- The harness posting something into the channel when it can't authenticate, so the failure appears where you're already looking
- A non-zero exit or an unhealthy signal so Docker/systemd notices, rather than staying up in a broken state

Worth noting the third agent, running `goose` against an API key instead of a subscription login, has zero auth errors over the same period. So this is specific to credential types that expire and need an interactive refresh.

Possibly related: #2265 — same shape (Claude agent silently stops working), different cause.

Start at the buzz_acp handling of session_prompt and agent_returned, then trace how presence is set to online. Reproduce the expired-credential case with claude auth status and a failing session_prompt in the headless Docker setup. Done means repeated Authentication required failures are surfaced through presence, a channel notification, or an unhealthy/non-zero process state.

Written by the indexing model from the issue text.