buzz-acp: after a *successful* reconnect the harness stops receiving mentions permanently, until the process is restarted

## Summary

After `buzz-acp` logs `autonomous reconnect succeeded` and `resubscribing to N channel(s) after reconnect`, it can stop receiving events **entirely and permanently** — not only for the reconnect gap. Mentions published many minutes later, on a stable connection, produce **zero** log activity in the harness. The relay accepts them and p-tags them correctly. Only restarting the process restores delivery.

The agent looks completely healthy throughout: process running, presence online, subscriptions logged, no errors on either side.

**This is not #4752.** That issue covers mentions lost *during* the gap and states that "mentions published while the connection is stable are processed normally". Here the connection is stable for 14 minutes afterwards and delivery never resumes. The resubscribe appears to succeed while restoring nothing. They may share a root cause, but the observable behaviour and the impact differ: #4752 loses a bounded window, this loses everything until human intervention.

## Environment

- `buzz-acp` build dated 2026-08-01, self-hosted relay, closed-mode NIP-42
- macOS 26.5.2, arm64, launchd-managed, `--subscribe mentions`
- adapter: `@zed-industries/claude-code-acp` 0.16.2
- reproduced on **three** agents across **two** machines and two OS accounts
- 34 `after reconnect` events in one log — churn is routine, not exotic

## Reproduction

1. Leave a `buzz-acp` agent running until the relay connection drops and auto-reconnects (minutes to hours; ours averages several per hour).
2. Publish a mention p-tagged to that agent, well after the reconnect completes.
3. Observe: relay returns `accepted:true` with the correct `mention_pubkeys`; the harness logs **nothing at all**.
4. Restart the harness. Publish the same mention. It is answered in seconds.

## Observed

Harness log, one agent, unedited except for truncation:

```
22:15:06.483 WARN buzz_acp::relay: relay connection lost — reconnecting…
22:15:06.664 INFO buzz_acp::relay: autonomous reconnect succeeded (attempt 1)
22:15:06.664 INFO buzz_acp: resubscribing to 8 channel(s) after reconnect
← 15 minutes with ZERO log lines, including across the mention below
22:30:46.141 INFO buzz_acp: presence set to offline (operator restart)
22:30:49.204 INFO buzz_acp: buzz-acp starting: …
22:30:49.873 INFO buzz_acp: subscribed to channel <8 channels>
22:30:49.873 INFO buzz_acp: presence set to online
```

Controlled test either side of that restart — same channel, same sender, same message text, single variable:

| time | event | result |
|---|---|---|
| 22:29:26 | mention published, `accepted:true`, correct `mention_pubkeys` | **no reply, zero log lines** |
| 22:30:49 | harness restarted | |
| 22:30:59 | identical mention published | **answered at 22:31:10** |

The relay side is fine: the same identity receives the events normally after restart, and a second agent on the same host was unaffected at that moment, so it is per-connection rather than relay-wide.

## Expected

After `resubscribing to N channel(s) after reconnect`, live delivery should actually resume for those channels. If the resubscription cannot be confirmed, that should surface as an error rather than an INFO line reporting success.

## Impact

This is worse than message loss because it is **indefinite and invisible**. There is no error, no retry, no queue entry, nothing in the log at all — a deaf agent is indistinguishable from an idle one. Concretely, for us:

- An agent ran for **7 days** appearing healthy and completed zero work.
- In a structured multi-agent discussion, two of three participants silently stopped answering mid-session. A non-answer is not distinguishable from a considered decision not to speak, so the resulting record reported consensus that was never tested.
- Monitoring based on process liveness and log errors reports everything green. The only reliable check we found is an end-to-end round trip: send the agent a token and require it back.

## Suggestions

- Verify the resubscription (await the relay's acknowledgement per channel) before logging success, and log a distinct error if it cannot be confirmed.
- Treat "no events received since reconnect" as a health signal and self-heal, rather than trusting the socket's own state.
- Failing both, expose a `--reconnect-max-silence` that recycles the connection after N seconds without inbound traffic — a blunt but effective backstop for the current behaviour.