fix(desktop): drive unread badges from live subscription, not refetched lastMessageAt

[tlongwell-block]

Bug

Phantom unread indicators on channels in the left sidebar: while sitting in one channel, a user sees an unread badge appear on another channel, and then some indeterminate amount of time later the badge disappears without the user ever viewing that channel.

Root cause

1. The Tauri get_channels command (desktop/src-tauri/src/commands/channels.rs) always returns last_message_at: null — it passes None for the summary argument to channel_info_from_event. The kind:40901 summary-sidecar path in nostr_convert.rs exists but is never wired up.
2. Live messages were bumping the React Query cache for the channel list via updateChannelLastMessageAt (in desktop/src/features/channels/lib/channelCache.ts), making the unread memo see a non-null lastMessageAt.
3. The 60 s refetchInterval on useChannelsQuery was then replacing the cache with the server response (which is null), wiping the live bump.
4. The unread memo dropped the channel because lastMessageAt was null again → badge disappears.

So the user sees a badge that appeared ~immediately after someone else posted in a channel, and disappeared up to 60 s later when the next channels-query refetch happened.

Fix

Stop relying on channel.lastMessageAt for the unread computation. Maintain an in-session Map<channelId, unixSeconds> inside useUnreadChannels, fed by a new onChannelMessage callback on useLiveChannelUpdates. Unread is now:

latest live timestamp strictly greater than the NIP-RS read marker
or the channel was manually marked unread this session

The callback is gated to human-visible content kinds (KIND_STREAM_MESSAGE, KIND_STREAM_MESSAGE_V2, KIND_FORUM_POST, KIND_FORUM_COMMENT) and skipped for the current user's own events:

• reactions, edits, deletions, diffs, and system messages would otherwise create phantom unreads when they arrive after the last real message
• your own outgoing messages should never mark a channel unread

channelCache.ts and all updateChannelLastMessageAt call sites are removed.

The first-load read-state seed now reads channel.lastMessageAt directly (today a no-op; future-proof for when the backend wires it up) rather than the live map, so a live event racing ahead of NIP-RS read-state readiness can't be silently swallowed as already-read.

Interaction with #578 (mark-unread context menu)

This PR was rebased onto main after #578 landed. The mark-unread feature exports markChannelUnread(channelId, lastMessageAt). Under the old model it relied on channel.lastMessageAt being populated by the live-event cache — broken when the backend returns null (always today).

Under this PR, manual mark-unread is tracked via a dedicated forcedUnreadRef: Set<channelId> separate from the live-timestamp map. The memo OR's forcedUnreadRef.has(id) into the unread set. markChannelRead clears the entry on reopen. This avoids synthesizing a fake "latest message" timestamp (which would otherwise make mark-unread sticky on reopen) and preserves AppShell's documented contract that passing activeReadAt: null suppresses read-marking until ChannelScreen reports a real timeline position. Net effect: mark-unread actually works under this PR, where it was previously broken on main.

Diff stats

 4 files changed, 142 insertions(+), 111 deletions(-)
 desktop/src/features/channels/lib/channelCache.ts        |  66 ----------
 desktop/src/features/channels/useLiveChannelUpdates.ts   |  39 ++++--
 desktop/src/features/channels/useUnreadChannels.ts       | 134 ++++++++++++++++---
 desktop/src/features/messages/hooks.ts                   |  14 ---

Out of scope

Tracked for follow-up, not addressed here:

• Backend get_channels returning a real last_message_at. Either wire kind:40901 summary-sidecar (path already half-built in nostr_convert.rs) or compute on read. Until that lands, channels that received messages while the app was closed won't show as unread until a live event arrives in-session. Same blind spot as today, no regression.
• First-load render-ordering bug in useUnreadChannels — the memo treats readAt === null as unread before the seed effect commits, causing a transient flash on app launch / identity switch. Different symptom from this bug; warrants its own fix.

Verification

• pnpm typecheck ✓
• pnpm check (biome + file-size guard) ✓
• Pre-commit hooks (rust-fmt, desktop-tauri-fmt, desktop-check, web-check, mobile-check) ✓
• Pre-push hooks (full rust tests, clippy, desktop-build, web-build, mobile-test, all checks) ✓
• Iteratively reviewed via codex CLI through six rounds; final scores 9/9/9 on minimalism, elegance, correctness. Caught and fixed: a first-load race silently swallowing real unreads; reactions/edits triggering phantom unreads; sticky synthetic-timestamp on mark-unread reopen; a contract violation around activeReadAt: null.

Manual test plan

1. Have two identities. Sit in channel A on identity 1.
2. Post a message in channel B from identity 2.
3. Identity 1's sidebar shows an unread dot on B. ✅ (this PR ensures it stays.)
4. Wait 60+ seconds without clicking B. Dot should remain. ✅ (previously: dot vanished here.)
5. Click into B. Dot clears (NIP-RS read marker advances).
6. Switch back to A. Have identity 2 post a reaction or edit in B. Dot does not appear (kind filter). ✅
7. Send a message yourself in B from identity 1. After switching back to A, no dot appears for B (self-author filter). ✅
8. Right-click a channel → "Mark unread". Dot appears immediately. ✅
9. Click that channel. Dot clears. Re-open from sidebar. Dot stays cleared (no sticky synthetic timestamp). ✅