Desktop reconnect replay re-alerts old thread replies and plays false notification sound

**Describe the bug**

Buzz Desktop plays the configured thread-reply notification sound after a
relay reconnect even when no new message has arrived. The visible timeline
does not show a duplicate, but an already-delivered thread reply appears to
pass through the desktop-notification callback again during reconnect replay.

The relay connection card itself is silent; the sound coincides with
`Reconnecting` → `Connected` because live channel subscriptions are replayed
at that point.

**Steps to reproduce**

1. In Buzz Desktop, enable desktop notifications and the **Thread replies**
alert row under Settings → Notifications.
2. Receive a reply in a thread the current user authored, participated in, or
follows.
3. Leave Buzz open without receiving any newer messages.
4. Interrupt the relay connection, or reproduce while the relay/load balancer
is temporarily unavailable, and allow Buzz to reconnect.
5. Observe that Buzz plays the configured notification sound after reconnect,
despite there being no new visible message.
6. Repeat the disconnect/reconnect. The same chirp can occur on every cycle.

Turning off only the **Thread replies** alert row suppresses the false chirp
while leaving the other alert classes enabled.

**Expected behavior**

Reconnect replay may redeliver an event to restore client state, but an event
ID that has already passed through the desktop-notification path must not
create another notification or play another sound.

**Version and platform**

- Buzz version: `0.4.26` (`xyz.block.buzz.app`)
- OS: macOS `15.1` (`24B2082`), Apple Silicon

**Logs / additional context**

This was observed during a relay incident in which other clients reported
`503 Service Unavailable`. A separate authenticated WebSocket probe connected
to the same relay recorded:

- `2026-07-27T21:19:20.826Z`: abnormal close `1006`, empty reason,
`wasClean: false`
- `2026-07-27T21:19:26.652Z`: reconnect opened; authentication accepted at
`21:19:26.957Z`
- `2026-07-27T21:19:29Z`: Buzz Desktop visibly reconnected and chirped
- `2026-07-27T21:19:42.490Z`: probe closed with `1006` again

The transport outage is only the trigger for this report. The client bug is
that reconnecting re-alerts an already-delivered event.

Source-level findings in the `v0.4.26` release:

1. `desktop/src/features/sidebar/ui/SidebarRelayConnectionCard.tsx` and
`useSidebarRelayConnectionCard.ts` contain no sound call.
2. `desktop/src/shared/api/relayReconnectReplay.ts` replays each live
subscription from five seconds before `lastSeenCreatedAt`.
3. That watermark is the latest event timestamp, not wall-clock time, so it
remains fixed during a quiet period and the same latest event can be
returned on every reconnect.
4. `prepareSubscriptionEvent()` in
`desktop/src/shared/api/relayClosedRecovery.ts` advances the timestamp but
does not deduplicate by event ID.
5. `desktop/src/features/channels/useLiveChannelUpdates.ts` has bounded
event-ID gates for DM and mention paths, but the qualifying thread-reply
path can call `onThreadReplyDesktopNotification` without an equivalent
gate.
6. `desktop/src/app/useAppShellDesktopNotifications.ts` plays the configured
`thread_reply` sound whenever that callback successfully sends the desktop
notification.

This establishes a source path that matches the one-chirp-per-reconnect
behavior. The exact replayed event ID is not available because the release
build does not log notification attempts or the event ID passed to the sound
call.

Suggested fix:

- Add bounded event-ID deduplication before invoking thread-reply desktop
notifications, retaining the set across reconnect replay.
- Add a regression test that delivers a thread reply, reconnects with the same
event in the replay window, and asserts that the notification/sound callback
runs exactly once.
- Consider adding a reconnect watermark for live subscriptions that have no
`lastSeenCreatedAt`, rather than resending the original subscription window.