fix(mobile): show live thread replies immediately

[developcoaching]

Summary

Fixes #3293.

Mobile channel subscriptions were discarding non-broadcast thread replies before they could update the root message's reply summary. This keeps each live reply as a temporary fallback until the relay's authoritative thread summary arrives.

The temporary reply is then removed in either delivery order, reply before summary or summary before reply, so the live overlay stays bounded. Broadcast replies remain visible in the main timeline.

This builds on the root-cause analysis in #3344 and adds retention cleanup plus event-order race coverage.

Changes

• Allow live non-broadcast replies into the channel window fallback.
• Remove covered replies when their authoritative thread summary arrives.
• Skip covered replies when the summary arrives first.
• Preserve broadcast replies as top-level timeline entries.
• Add provider and channel-window regression tests.

Verification

• just ci
• 1,027 mobile tests passed, with one expected skip.
• 2,088 desktop Rust tests passed, with 14 expected ignores.
• Independent adversarial review verdict: NO BLOCKERS.

[kerpopule]

Confirmed with a live Buzz 0.5.3 mobile + Hermes managed-agent canary. Mobile sent the explicitly addressed DM; Hermes ACP received it at 2026-08-02 00:39:32 CDT and completed at 00:39:49 with response_len=111. The reply did not render on mobile until the app was closed and reopened. General-channel replies were already rendering. This is the exact force-reload symptom from #3293, and the focused tests on this PR pass locally: flutter test test/features/channels/channel_messages_provider_test.dart test/features/channels/channel_window_test.dart (36 passed).