fix(desktop): preserve theme when opening communities

[tellaho]

Category: fix
User Impact: Previously selected community themes are preserved when opening a relay through onboarding, while first-time theme migration still completes for communities with no saved theme.

Problem: During community initialization, desktop queried theme history before establishing live delivery. If a replacement event arrived while an empty history query was in flight, the client could incorrectly treat the theme as absent and publish the default over the user's saved selection.

Solution: Subscribe before fetching history, expose whether live readiness reached EOSE, flush buffered live events before resolving EOSE, and retain the newest delivered replacement through hydration. Seed the inherited/default theme only when both live and history snapshots reach EOSE with no valid or unreadable event; subscription failures, CLOSED, readiness timeout, relay failure, and unreadable events fail closed without publishing.

File changes

desktop/src/shared/api/relayClientSession.ts / relayClientShared.ts / relayClosedRecovery.ts
Distinguish EOSE from CLOSED/timeout readiness and flush buffered events before resolving an EOSE fence.

desktop/src/shared/theme/CommunityThemeController.tsx
Seed and complete first-community migration only for confirmed absence; uncertain hydration remains non-publishing.

desktop/src/shared/theme/communityThemePreference.ts
Keep the inherited appearance for the first migrated community and the stable default for later empty communities.

desktop/src/shared/theme/communityThemeSync.ts
Arbitrate live and history results into valid, confirmed-absent, invalid, or unavailable hydration outcomes.

Tests
Cover EOSE/CLOSED readiness, subscription failure, timeout, unreadable and live-racing events, no-op initialization, and first-to-later community fallback isolation.

Reproduction steps

1. Save a non-default appearance for a community relay.
2. Remove the community locally, then open the same relay again through onboarding.
3. Arrange for the saved replacement event to arrive live while the initial history query returns empty.
4. Confirm the saved appearance remains selected and the client does not publish the default theme over it.
5. On an account with no theme records, open a first empty community and confirm its inherited appearance is migrated; open a later empty community and confirm it starts from the stable default.

Validation

• Pre-push desktop checks, typecheck, and full desktop tests: passed at f79556b0e
• Focused theme/relay readiness tests: 38 passed
• Desktop file-size ratchet and diff check: passed

[wesbillman]

Reviewing on Wes's behalf. The subscription-first arbitration is sound, but this patch removes the only successful-absence migration path entirely. On an account with no remote/local/outbox theme, hydration now does nothing: it neither persists the first community's inherited global appearance nor calls markCommunityThemeMigrated. Because that marker remains false, every later community with no record continues using initialPreferenceRef.current instead of the stable default, contrary to the controller's scope-isolation contract. This is a user-visible regression for accounts without an existing relay theme, not merely a documentation issue. Please preserve fail-closed behavior for uncertain states while adding a trustworthy confirmed-absence path that completes migration/seeding, and cover the controller-level sequence: first absent community migrates the inherited appearance; a later absent community receives DEFAULT_COMMUNITY_THEME rather than the first community's appearance. The PR body also currently says a default is seeded when neither source finds a preference, but this head never seeds on hydration.

[wesbillman]

Reviewing on Wes's behalf. The code path is clean in my re-review, but the current head cannot merge under this repo's authorship policy: commit f79556b0ef37850cd7cfe3a63acf30fe23749e3b is authored and signed off by Carl. For block/buzz changes made on Wes's behalf, Wes must be the commit author and Signed-off-by, with the implementing agent only in Co-authored-by.

Please rewrite that commit so its author and sign-off are Wes <wesbillman@users.noreply.github.com>, retaining Carl as co-author, then force-push and let CI/DCO validate the rewritten head. This is my mistake from the implementation pass, not Taylor's.

Dismissed after re-review: the behavioral issue is fixed, and Wes explicitly accepts the current commit attribution.

[wesbillman]

Re-review by Carl on Wes's behalf at exact head f79556b0ef37850cd7cfe3a63acf30fe23749e3b: the prior behavioral blocker is fixed and no code findings remain. Wes explicitly accepts the current Carl-authored commit attribution, so I have dismissed both stale changes-requested reviews. The PR is mergeable and all applicable checks are green. Per policy, Wes retains approval authority.