buzz-acp: mentions sent while an agent session is stopped are silently lost — no backfill/replay when the agent starts (must resend live)

## Summary

A `@`-mention sent to a managed agent **while that agent's session is not running** is accepted and persisted by the relay (it renders fine in Desktop via backfill) but **never wakes the agent** — and, critically, **starting the agent afterward does not replay it**. The human has to send the mention *again*, live, while the session is up. This is a silent-loss failure: the sender sees their message land in the channel but gets no response and no error.

The mention **transport is fine** — the event carries the correct `["p", ]` tag and a live-session agent wakes on the identical event. The gap is purely **agent-session liveness + no startup catch-up**: on start, a session subscribes to *new* events only and does not backfill unhandled mentions that arrived while it was down.

## Environment

- Buzz Desktop 0.5.8 (0.5.8), macOS (Darwin 25.6.0)
- Managed agents via the buzz-acp / Hermes ACP harness (local runtime)
- Mention composed from the **mobile** client; agents hosted on **Desktop**

## Reproduction (clean, from a live session on 2026-08-10)

Confirmed with two side-by-side cases in the same channel:

**Case A — agent session live → works**
1. Agent `Fizz` session running in Desktop.
2. From mobile, send `@Fizz ...`. Event `86524ec7c034c3af96b434b867bf67e759a5873e58dea38967be8e6e7a2a0b1d`.
3. Raw event tags (pulled from relay): `["h", ]`, `["p", "97897d93…"]` ← correct mention tag.
4. Agent wakes and replies. ✅

**Case B — agent session stopped → silently lost, no replay on start**
1. Agent `Bumble` **not started** in Desktop.
2. From mobile, send `@Bumble ...`. Message appears in Desktop (backfill render); **no response**.
3. **Start** Bumble in Desktop. The already-delivered mention is **not** replayed — still no response.
4. Send the mention **again** while Bumble is now live → it responds. ✅

The only difference between B-fail and B-success is whether the session was live at the instant the event hit the relay. Nothing about the event itself changed.

## Expected behavior

When an agent session starts (and on Desktop/relay reconnect), it should **backfill and process unhandled mentions newer than its last-processed event**, so a mention sent while the agent was stopped triggers exactly once when the agent comes online — without the human resending. At minimum, a missed mention should surface a visible status rather than disappearing silently.

## Suspected root cause

Same shape as the startup-sync gap documented in #4893: startup performs a single history fetch + a live subscription with `limit: 0` (new events only), with no backfill/retry of the mention stream. Mentions that landed during downtime fall into the gap between "last seen before stop" and "first live event after start."

## Related issues (agent-wake / mention-delivery cluster)

- #4903 — buzz-acp: online mentions can be silently lost before enqueue (closest, but the agent was **online**; this report is the **offline/stopped** corner)
- #5495 — Agent (Mountie) failed to respond to DM mentions — reliability gap (same symptom class, surface-level)
- #5007 — Agent mention notifications not consistently delivered (multi-mention fan-out)
- #4893 — Desktop: agent definitions permanently missed after startup sync failure (**same root-cause shape**, applied to kind:30175 definitions instead of mentions)

## Impact

Agents appear unreliable/"off." Because the message visibly lands but nothing happens and no error is shown, users can't tell whether the agent is down, backlogged, or ignoring them — and the only workaround (start the agent, then resend) is non-obvious.

Start by tracing buzz-acp agent-session startup, the initial history fetch, and the live subscription using limit: 0, then compare the flow with the startup-sync gap described in #4893. Reproduce the stopped-session case and verify that a mention received during downtime is backfilled and processed exactly once on startup or reconnect, without resending.

Written by the indexing model from the issue text.