Live thread-summary push: badge counts update on reply ingest

[tlongwell-block]

Problem

Two badge symptoms reported on staging (thread: buzz-relay-optimization), one root cause:

• Frozen live counts — the reply count on a thread's timeline row never increments while replies arrive live; it only updates after reconnect/re-entry/scrollback.
• Missing badges — rows that reach the screen via the live overlay or refetch reconciliation show no thread badge at all until scrollback re-delivers them as page rows.

Mechanism (full trace in RESEARCH/THREAD_COUNT_BADGE_MECHANISM_2026_07_05.md on my workspace, summarized in the PR thread): badge counts come exclusively from relay-signed kind:39005 overlays attached to channel-window page responses — a snapshot frozen at fetch time. thread_metadata is already updated transactionally on every reply insert, but the relay never told anyone. Live replies deliberately skip the main timeline store, so the client can't compensate locally.

Fix: the relay pushes what it already knows

Relay (side_effects.rs, call sites in ingest.rs + delete handlers):

• After a reply insert commits — and after threaded deletes decrement counters — sign a fresh 39005 from thread_metadata and broadcast it through the existing Redis + local fan-out paths (same access gating as every other event).
• Same tags/content contract as the page overlay in api/bridge.rs: one contract, two delivery doors.
• Never stored. Pages recompute summaries from thread_metadata on every fetch; a persisted copy would only add staleness. 39005 is relay-signed, so clients can't spoof counts.
• Counts are re-read post-commit, not incremented, so pushes are exact under concurrent replies/deletes, and deletes count down.
• Spawned fan-out — zero added latency on the ingest acknowledgement.

Desktop:

• The channel live subscription (subscribeToChannelLive) adds kind 39005 — scoped to this one subscription, not CHANNEL_EVENT_KINDS, so unread tracking and timeline caches never see summary overlays.
• Window store gains a liveSummaries overlay: newest created_at wins per root; cleared by the authoritative head refetch; survives scrollback pages (a racing push can be fresher than a just-fetched page summary). Merged over page summaries in channelWindowThreadSummaries — which also fixes the missing-badge symptom for rows that never got a page summary.
• The existing local reply merge in useLiveChannelUpdates is intentionally kept: badge rendering resolves local-vs-relay counts via max() in mergeThreadSummaries, and without the local path a new client against an old relay (no 39005 push) would freeze counts entirely. (An earlier revision of this branch removed it and promptly broke the thread-badge smoke suites — CI caught it; reverted.)

Backward compatible both directions: old clients ignore the pushed 39005 (parameterized-replaceable, never stored); new clients against an old relay degrade to today's fetch-time snapshot behavior.

Mobile (post-#1518 channel windows) has the same gap — follow-up, not this PR.

Validation

• Ignored e2e test_reply_ingest_pushes_live_thread_summary, run against a real local relay: subscribe with the desktop-shaped filter, reply → pushed summary with reply_count: 1, delete the reply → pushed summary with reply_count: 0. Both received live, no window refetch.
• Window-store unit tests: overlay wins over page summary, badge for page-less roots, stale-push rejection (identity-stable), head-refetch clearing, scrollback survival.
• Response-parser unit tests: well-formed parse + malformed/mistargeted drops.
• cargo test -p buzz-relay: 463 passed. cargo clippy --tests: clean.
• Desktop typecheck / check / test (1623): all green; thread-badge smoke suites (messaging:561, thread-unread, thread-reply-anchor-roleplay, human-edit-agent-content, spoiler:145) pass locally against the built bundle.

Also cherry-picks the ChannelScreen size-gate trim from #1520 (main's Desktop CI is currently red without it; drops out on rebase if #1520 merges first).