feat(theme): persist useWallpaperColors preference + dynamic ColorScheme branching

[ilmoniemi]

What

Adds a third DataStore-backed preference (use_wallpaper_colors, default false) on AppPreferences, with a Flow<Boolean> and suspend setUseWallpaperColors. MainActivity.setContent collects it next to themeMode and passes it into the existing dynamicColor: Boolean parameter on PyrycodeMobileTheme. The theme's internal Build.VERSION.SDK_INT >= S gate already routes pre-S devices to the brand palette even when dynamicColor = true, so no extra SDK check is needed at the call site. Theme.kt is untouched.

This slice is invisible-by-default — the only way to flip the preference is programmatically. The visible Settings switch row lands in #89.

Issue

Closes #88

Testing

• ./gradlew test — passes; adds useWallpaperColors_defaultsToFalse and setUseWallpaperColors_roundTripsBothValues to AppPreferencesTest (real PreferenceDataStoreFactory + TemporaryFolder, mirroring the existing pairedServerExists / themeMode tests). Confirmed RED → GREEN before commit.
• ./gradlew lint — clean.
• ./gradlew assembleDebug — succeeds.
• ./gradlew connectedAndroidTest — not run (no device/emulator attached in this worktree); no instrumented tests added in this slice.
• ./gradlew spotlessCheck — fails on a pre-existing violation in ui/settings/ThemePickerDialog.kt (from feat(theme): persist ThemeMode preference + reactive PyrycodeMobileTheme wiring #86) that is outside this ticket's scope. The files in this diff are spotless-clean.

Manual smoke test (re-collection re-renders without process restart)

Per AC: collectAsStateWithLifecycle(initialValue = false) makes dynamicColor a state read inside the setContent composition, so writes via setUseWallpaperColors trigger recomposition and the when block inside PyrycodeMobileTheme re-resolves the ColorScheme. I did not run an emulator-side toggle in this PR because there is no caller for the setter yet (#89 wires it). The setter is exercised by the round-trip unit test, and the live-re-theme behavior is the standard semantics of collectAsStateWithLifecycle already used for themeMode in #86.

Architecture compliance

Follows docs/specs/architecture/88-use-wallpaper-colors-preference.md exactly:

• Mirrors pairedServerExists's shape for the new key + flow + setter.
• New companion constant USE_WALLPAPER_COLORS = booleanPreferencesKey("use_wallpaper_colors").
• Composition-root collection added next to themeMode; theme call gains dynamicColor = useWallpaperColors.
• Theme.kt not edited — extends the feat(theme): persist ThemeMode preference + reactive PyrycodeMobileTheme wiring #86 convention of "caller passes a Boolean, theme function resolves internally."
• No DI changes (per spec — AppPreferences is already a Koin single).

🤖 Generated with Claude Code

[ilmoniemi]

Code Review: #88

Decision: PASS

Findings

• [NIT] CI (:spotlessKotlinCheck) is red, but the violation is pre-existing in app/src/main/java/de/pyryco/mobile/ui/settings/ThemePickerDialog.kt:48-52 — that file is untouched by this PR and the same formatting issue exists on main (introduced in feat(ui): Settings theme picker dialog (System / Light / Dark) #87). The PR description correctly flags this as out of scope. Recommend a tiny follow-up PR running ./gradlew :spotlessApply so CI is green for the rest of the Appearance row stack (feat(ui): Settings — "Use wallpaper colors" switch row #89, etc.).
• [NIT] setUseWallpaperColors has no production caller in this slice. Intentional per spec (the setter is reserved for feat(ui): Settings — "Use wallpaper colors" switch row #89's switch row); flagging only so reviewers don't trip on "dead code" — it's load-bearing for the sibling ticket.

Summary

The diff matches docs/specs/architecture/88-use-wallpaper-colors-preference.md exactly:

• AppPreferences.kt:31-36,41 — new boolean key + flow + suspend setter cloned verbatim from the pairedServerExists shape, as the spec prescribed. booleanPreferencesKey("use_wallpaper_colors") with a ?: false default. No new imports.
• MainActivity.kt:62-63,70 — flow collected with collectAsStateWithLifecycle(initialValue = false) right next to the existing themeMode collection; PyrycodeMobileTheme call gains one named arg dynamicColor = useWallpaperColors. Initial value matches persisted default — no first-frame flash.
• Theme.kt correctly not edited. Reuses the existing dynamicColor: Boolean = false parameter whose internal Build.VERSION.SDK_INT >= S gate (Theme.kt:275) handles the pre-S fallthrough to the brand palette. This is the right call: changing PyrycodeMobileTheme's signature would have rippled through 18+ @Preview composables, and the spec explicitly forbade it.
• AppPreferencesTest.kt:80-95 — useWallpaperColors_defaultsToFalse + setUseWallpaperColors_roundTripsBothValues (with an extra true → false step at the end so the final state is non-default). Mirrors the existing pairedServerExists test pattern. The spec's third optional test (flowReemitsAfterWrite) was correctly dropped as redundant — each first() resubscribes, so the round-trip already exercises re-emission.

Mechanical / blast-radius checks

• Diff is purely additive — no signature changes, no removals. Zero call sites to update.
• No Color(0xFF…) / TextStyle() literals introduced (invisible-by-default slice; no UI surface).
• No android.* imports in data/ (portability rule respected).
• No !!, no GlobalScope, no runBlocking outside tests, no direct Dispatchers.IO.
• No new dependencies in gradle/libs.versions.toml.

Architecture compliance

Matches the convention #86 established (caller passes a Boolean, theme function resolves internally). State + concurrency model is identical to themeMode and pairedServerExists. The decision to skip error handling at this layer is consistent with existing precedent and the spec's evidence-based-fix call-out.