fix(android): preserve selected theme after startup loading cover

[svenons]

Summary

With Appearance set to Light (or Auto in system light mode), the app could open
"half black" after a cold start or reopen: Material surfaces followed
Appearance while legacy RelayRefresh.* surfaces and system-bar icon contrast
stayed dark until Appearance was toggled.

The in-app navigation-hydration cover rendered SupervisedStartupLoadingScreen(),
which opens a nested HermesRelayTheme(themePreference = "dark"). Its
SideEffect overwrote the global RelayRefresh.activePalette and system-bar
contrast, and the outer theme did not recompose after the cover was removed.

Closes #678

Changes

• Split loading content from its theme wrapper. The in-app navigation cover inherits the selected Appearance theme; the pre-runtime loading screen retains its own dark theme.
• Added seven API 36 Robolectric render cases covering Light, Auto with system light/dark, Dark, a fixed dark preset, and a custom light palette. The tests repeat hydration, route-denial covers, and composition-root recreation, checking the shared palette and both system-bar contrast flags without relying on outer-theme recomposition.
• Included the regression class in required CI and the on-demand focused test selection, and documented the local verification command.

Verification

Maintainer follow-up, before the final base refresh:

• :app:testSideloadDebugUnitTest and :app:testGooglePlayDebugUnitTest, selecting StartupLoadingThemeTest, RelayNavigationHydrationUiTest, SupervisedNavigationPolicyTest, and PersistedAppearanceThemeTest: 23 tests passed per flavor.
• :app:lintSideloadDebug :app:lintGooglePlayDebug: passed with zero errors after fresh lint analysis.
• Restoring the old nested-theme call made the regression fail with a dark legacy palette in Light mode; restoring the fix passed.
• Rendered loading covers and Material/legacy palette samples were inspected. These fixtures exercise composition handoff and window contrast flags; they do not certify process death or device-specific behavior.
• Current-head hosted results are in this PR's Checks tab. The full local unit-test suite was not rerun.

Maintainer physical-device verification on e891b8981:

• Updated the existing matching-signed Hermes Dev installation on a Samsung SM-S938U, Android 16/API 36, without clearing app data. The installed APK hash matched the locally built artifact.
• 24 launches passed: three force-stop launches and three warm reopens for each of Dark, Light, Auto/system-light, and Auto/system-dark. Process IDs distinguished cold starts from warm reopens.
• Expected background and legacy-surface colors, both system-bar appearance flags, and inspected screenshots remained consistent. No crash-buffer entries were found for the twelve tested process IDs.
• Restored Auto, the Relay preset, and the original system dark mode. Tests used the disconnected app state; live-server/policy-owner hydration was not forced on the phone. The automated render tests cover deterministic loading-cover transitions.

Contributor verification from the original PR:

• ./gradlew :app:lintSideloadDebug and ./gradlew :app:assembleSideloadDebug passed.
• The broad local unit-test run was not clean: 233 Robolectric failures attributed to a local JDK incompatibility (Failed to interact with raw FileDescriptor internals), plus two unrelated voice-routing/git ViewModel timeouts.
• Pixel 7 Pro, Android 17, build 2026100201: repeated reopen and force-stop launches with Light and Auto (system light) no longer left dark surfaces. This remains contributor-reported evidence for the Pixel / Android 17 environment.

Screenshots

Pixel 7 Pro, Android 17, Appearance Light.

Before	After

Compatibility / risk

• Android client only; no server, plugin, or upstream Hermes dependency.
  Standard Hermes path unaffected.
• No migrations, persisted state, or security/privacy impact.
• Rollback: revert the loading-cover change.

Lineage / contributor credit

• Original contributor commits d27e08a5 and fd90b433 are retained unchanged.
• Maintainer follow-up adds regression coverage, CI selection, documentation, and the current dev base merge.

Checklist

• Target branch is dev, unless this is a dev → main release PR or a focused production-tag hotfix PR to main
• Scope is focused and related issues/PRs are linked
• Android changes: lint and focused tests ran, or rationale is listed above
• Translation changes: locale validation/review ran, or N/A is listed above — N/A
• Server/plugin changes: focused tests ran, or N/A/rationale is listed above — N/A
• Desktop changes: build/tests ran, or N/A/rationale is listed above — N/A
• Docs/site changes: build or link/route checks ran, or N/A/rationale is listed above — N/A
• UI changes were tested on a relevant device/emulator/desktop surface, or the missing proof is stated above
• Commit messages follow Conventional Commits
• CHANGELOG.md is updated for user-visible changes, or N/A is listed above
• Public writing hygiene checked: no secrets, private infrastructure, personal names, or AI/process narration
• Salvaged/replacement work links source PRs and preserves contributor authorship, or N/A is listed above

[hermes-relay-triage]

🤖 Hermes-Relay automated PR intake

Thanks for tackling the startup theme issue! This targets dev, links #678, and includes the template sections, a changelog update, exact verification commands, and before/after screenshots with Pixel 7 Pro device checks.

Lint and assembly are reported as passed. The local unit-test failures/timeouts and lack of a new regression test are explicitly documented; no CI results are visible yet. The remaining verification item is a required CI result for this PR head, rather than treating the local unit-test run as a pass.

A maintainer will review the change and the outstanding unit-test evidence.