fix(mobile): retry channel-sections startup sync when relay rate-limits cold start

[tellaho]

Category: fix
User Impact: Channel groups created on desktop now reliably appear on Android and iOS on cold start, instead of falling back to the default ungrouped list.

Problem: On mobile cold start, ChannelsNotifier fires ~25 per-channel REQs at once, exhausting the relay's per-connection rate-limit quota. ChannelSectionsManager then gets BOTH its one-shot history fetch and its live subscription rejected with rate-limited: quota exceeded — and both errors were silently swallowed (catch (_)) with no retry, so the manager kept the local (empty/default) store forever. Restarting the app repeats the same storm, so Android reliably lost the race every launch. Captured live on the emulator with instrumentation.

Solution: Track whether the startup fetch and the live subscription have each succeeded, and retry _syncWithRelay with exponential backoff (2s base, shift-capped, 30s max) until both land. The retry timer is cancelled on dispose, and previously-swallowed errors are now logged.

Based directly on main — independent of #2829 (which fixes the write path: unpublished local edits being clobbered). The analogous retry for ChannelSortManager lives in #2829, since that manager is introduced there.

File changes

mobile/lib/features/channels/channel_sections/channel_sections_manager.dart
Extract the startup fetch + live-subscription into _syncWithRelay, track success of each step, and schedule a backoff retry until both succeed. _fetchAndMerge and _startLiveSubscription now report success; swallowed errors are logged; retry timer cancelled on dispose. startupRetryBaseDelay ctor param is test-visible.

mobile/test/features/channels/channel_sections/channel_sections_manager_test.dart
New regression tests with a rate-limiting relay fake: remote sections are adopted after retries; retry stops once fetch + subscription succeed; dispose cancels pending retries.

Reproduction Steps

1. On desktop, create channel groups (sections) for an account.
2. Cold-start the Android app for the same account on a relay with per-connection rate limiting and enough joined channels to trigger the REQ burst (~25 channels reproduced it reliably).
3. Before this fix: logs show fetch FAILED: Exception: rate-limited: quota exceeded and the live subscription failing, then silence — the channel list renders the default ungrouped list forever, surviving app restarts.
4. With this fix: logs show startup sync incomplete; retrying in 2000ms (attempt 1), the retry succeeds, and the desktop-created groups render.

Verification

• Live on emulator-5554 (earlier stacked build of the same logic): cold start reproduced the manager being rate-limited, then a single 2s retry succeeding and groups rendering, matching desktop channel-for-channel.
• Full mobile suite run at this exact head (c5f1d9a): 654 passing; the 4 failures (3× compose_bar_test, 1× channels_page_test) reproduce on unmodified main (74b63e1) — pre-existing, unrelated. flutter analyze clean on both touched files.

Originating thread: Buzz channel ed3994af-0949-447c-be00-29f03965b52e, root 4bf7cbfd48bf.

[tellaho]

Recreated from #2995 (same head c5f1d9a38, identical diff) to move to the tho/ branch prefix. Marge's review/approval of this exact head is on #2995.

[wpfleger96]

Reviewed at head c5f1d9a38. Combined and deduplicated feedback from three independent reviewers (Paul, Thufir, Duncan) — each formed findings separately before seeing the others.

This is a good PR: small, single-purpose, and the emulator reproduction in the description is exactly the right kind of evidence. Diagnosing the catch (_) swallowing as the reason the manager kept empty state forever is correct, and the retry is the right shape. No CRITICAL findings.

One IMPORTANT: the retry can fail to fire in the very scenario it targets, because subscribe() reports success on a readiness timeout. Details inline. Two MINORs on the backoff, also inline.

Worth stating what we verified rather than assumed — the null-vs-false distinction the retry rests on does hold. A rate-limited REQ produces a relay CLOSED (crates/buzz-relay/src/connection.rs:655-679 routes every admission rejection through request_rejection_message, which emits CLOSED whenever a sub_id is present, and a REQ always has one), which relay_session.dart:503-509 turns into a thrown error rather than an empty result. So a rate-limit can't masquerade as "relay has no sections blob." We specifically went looking for a hole there and there isn't one.

CI is green, and none of the findings below are CI-detectable.