Relay liveness watchdog: detect and recover dead subscriptions

[Catrya]

Split from #277 (its cause 2). Causes 1 and 3 are fixed; this tracks the
remaining one.

Problem

The websocket can go completely silent — no Kind 38383, no kind-14, no
error, no reconnect — and the app never notices. Documented in #277: a
22-minute total silence during an active trade, recovered only by a manual
app restart; meanwhile the daemon's messages (the seller's turn to pay the
hold invoice) were missed and the order was canceled by timeout.

On Android we also observed both relays dropping together roughly every
60 seconds (connect/disconnect cycles in lockstep), which points to OS
power/network management killing the sockets rather than relay-side issues.

Proposed direction

• Investigate what nostr-sdk already offers (relay ping / health status /
  auto-reconnect hooks) before building anything.
• A silence watchdog: if no event or EOSE arrives on the active
  subscriptions for N minutes, force a reconnect + resubscribe under the
  same stable subscription ids.
• Resubscribe on app resume (foreground transition), which is when the
  Android socket kills are most likely to have happened.

Notes

• With # merged, a recovered subscription now replays and
  decrypts the missed kind-14 backlog correctly, so recovery is actually
  effective — before it, reconnecting was not enough.
• Related hygiene: Subscription lifecycle cleanup: unsubscribe + deterministic IDs (supersedes #144) #182 (subscription lifecycle cleanup).

[codaMW]

Picking this up. Did the nostr-sdk investigation first, as suggested — findings and proposed approach:

What the SDK (0.44.1) already handles: the per-relay connection task auto-reconnects a dropped socket on its own (this is why our spawn_status_monitor sees relays cycle Connected→Disconnected→Connecting→Connected). RelayPoolBuilder also exposes a Monitor for status observation, and try_connect(timeout) forces connection attempts. So the ordinary drop-and-reconnect case is covered.

What it does NOT handle — and is exactly this bug: the silent case. Our status monitor polls client.relay(url).status(), which is connection state, not data liveness. When the OS half-kills a socket, the SDK can still report Connected while no events flow — the 22-minute total silence from #277 with no status transition, no error, no reconnect. Nothing in the SDK detects "connected but silent."

Proposed approach:

1. Track last_event_at on the pool, bumped by the existing notification loops (orders/messages already see every RelayPoolNotification::Event).
2. A silence watchdog beside the status monitor: if no event/EOSE for N minutes while the pool believes it's Online, force a disconnect + try_connect. Crucially, the reconnect drives our existing ConnectionState::Online handler in nostr.rs, which already re-fetches capabilities, flushes the outbox, re-subscribes orders, and rebuilds chat listeners under the same stable subscription ids — so recovery reuses proven machinery rather than duplicating it.
3. Resubscribe on app-resume (foreground), which is when the Android socket kills are most likely — this needs a small Dart lifecycle→Rust hook, which doesn't exist yet.

Scoping: I'll land (1)+(2) — the core watchdog that fixes the reported silent-death — as the first PR, and do the resume hook (3) as a fast follow-up, since it touches Dart lifecycle and is cleanly separable. Will device-verify on Android by backgrounding to trigger the socket kill and confirming recovery. Proposed silence threshold ~3–4 min (above the ~60s Android cycle, well under the 22-min failure) — open to a different N if you have a preference.