buzz-acp: mentions published during a WebSocket reconnect gap are silently lost (resubscribe uses now, not last-seen)

## Summary

When the relay WebSocket drops (frequent on hosted communities) and `buzz-acp` reconnects, mentions that arrived **during the gap** are never delivered to the agent. The harness resubscribes with a `since` filter anchored near resubscribe time rather than the last-seen event, so anything published while it was disconnected is silently skipped. The agent looks perfectly healthy — connected, subscribed, presence online — and simply never answers.

## Observed

On a hosted community (`*.communities.buzz.xyz`), one agent (remote harness per `docs/remote-agents.md`, systemd, 0.5.2 binaries):

```
WARN buzz_acp::relay: WebSocket error in background task: IO error: Connection reset by peer (os error 104)
INFO buzz_acp::relay: autonomous reconnect attempt 2/5 …
INFO buzz_acp::relay: autonomous reconnect succeeded (attempt 2)
INFO buzz_acp: resubscribing to 3 channel(s) after reconnect
DEBUG buzz_acp::relay: subscribed to channel (with since filter) since=1785863443
```

Three owner/peer mentions published in that window (verified p-tagged to the agent, `accepted=true` at the relay) produced **zero** log activity in the harness. An independent WS client using the same agent identity and a `{"kinds":[9],"#h":[channel],"since":…}` filter received the same events fine, so the relay side is correct. Mentions published while the connection is stable are processed normally.

Reconnect churn on this community is 4–9 drops per agent per hour, so gaps are routine, not exotic.

## Expected

After a reconnect, the harness should backfill: resubscribe from the last event timestamp it actually processed (or query the gap explicitly) so no mention is lost. Alternatively expose a bounded catch-up window as config.

## Impact

Silent, unattributable message loss — the failure looks identical to "the agent ignored me". There is no error, no queue entry, and no way for a user to tell a dropped mention from a slow one. On flaky links agents appear randomly unreliable, which is corrosive for teams relying on them.

Related: this makes NIP-42-authed live subscriptions on unstable networks lossy in general, not just for mentions.

Start in the Rust `buzz_acp::relay` reconnect and resubscribe flow, using `docs/remote-agents.md` for the remote-agent context. Trace how the last processed event and the `since` filter are chosen, then verify with a reconnect-gap scenario that mentions published during the gap are recovered without duplicating processed events.

Written by the indexing model from the issue text.