feat(ui): Settings theme picker dialog (System / Light / Dark)

[ilmoniemi]

User Story

As a Pyrycode mobile user, I want to tap the Theme row in Settings and pick System default / Light / Dark, so I can override my phone's appearance for this app.

Context

The Settings screen (#64) shows a Theme row with a chevron, but onClick = {}. The data path — ThemeMode enum, theme_mode DataStore key on AppPreferences, and reactive theming wiring — landed in sibling slice #86. This ticket adds the user-facing affordance: a single-choice radio dialog that writes the user's pick via AppPreferences.setThemeMode(...).

What #86 left in place:

• MainActivity collects AppPreferences.themeMode at the root for PyrycodeMobileTheme(darkTheme = …), AND a second time inside composable(Routes.SETTINGS) { … } to pass themeMode: ThemeMode as a parameter into SettingsScreen(...).
• SettingsScreen takes a themeMode: ThemeMode = ThemeMode.SYSTEM parameter and renders its subtitle via a private ThemeMode.label() extension.

What this ticket changes: the Settings route stops injecting AppPreferences directly and stops passing themeMode as a parameter — it obtains a SettingsViewModel via koinViewModel(...) and forwards state + an event callback into SettingsScreen. The Theme row gains a tap handler that opens the picker dialog.

Material You dynamic color is a separate (future) ticket — this one is ONLY system/light/dark.

Acceptance Criteria

• Tapping the Theme row opens a single-choice dialog titled "Theme" with three radio rows labelled "System default" / "Light" / "Dark" (same strings as the row subtitle — see existing ThemeMode.label() at SettingsScreen.kt:266); the currently-selected radio reflects the persisted ThemeMode.
• Confirming the selection persists via AppPreferences.setThemeMode(...); cancelling (or dismissing without confirming) leaves the persisted value unchanged. The architect chooses the M3-spec dialog shape (OK/Cancel buttons vs. tap-radio-to-commit-and-dismiss) — either is acceptable.
• After a confirming selection, the Theme row subtitle updates and PyrycodeMobileTheme re-renders with the new scheme without a process restart. (Both surfaces collect the same AppPreferences.themeMode flow — MainActivity at the root for the theme, the new SettingsViewModel for the row — so a single setThemeMode(...) write fans out to both.)
• A SettingsViewModel (Koin-injected via AppModule) exposes themeMode: StateFlow<ThemeMode> and an onSelectTheme(mode: ThemeMode) event entry point. The composable(Routes.SETTINGS) { ... } block in MainActivity obtains it via koinViewModel<SettingsViewModel>() and forwards state + callback into SettingsScreen, replacing the current direct AppPreferences injection and themeMode parameter. Full sealed SettingsState / SettingsEvent types are NOT required at this slice's scope; only the selected ThemeMode and the callback need to be hoisted out of the composable.
• SettingsViewModelTest covers: initial state mirrors AppPreferences.themeMode; selecting each mode persists via the fake; the exposed flow re-emits after persistence.

Technical Notes

• The ViewModel may depend on AppPreferences directly — no new repository.
• The dialog's open-state can be a remember { mutableStateOf(false) } local to the Settings composable; only the selected ThemeMode and the event callback need to be hoisted to the ViewModel.
• ThemeMode.label() is already a private extension at SettingsScreen.kt:266. Architect's call: either promote it (file-level or into data/preferences/) and reuse for the dialog's radio labels, or duplicate the three-case when locally in the dialog. Don't write a third copy.
• The dialog itself can live as a private composable in SettingsScreen.kt or in its own file under ui/settings/. Architect's call.

Depends On

• ✅ feat(theme): persist ThemeMode preference + reactive PyrycodeMobileTheme wiring #86 (merged in 2cd2c85) delivered ThemeMode enum, theme_mode DataStore key on AppPreferences, root-level PyrycodeMobileTheme wiring in MainActivity, and the Theme row subtitle. This ticket builds on those primitives.

Figma

https://www.figma.com/design/g2HIq2UyPhslEoHRokQmHG?node-id=17-2

The Theme row that opens this dialog lives in node 17-2 (Settings Screen). The picker dialog itself has no Figma sub-node — implement with M3 single-choice dialog defaults. If the visual diverges meaningfully from M3 defaults later, a Figma-side ticket can capture it; for this slice, M3 defaults are the spec.

Size Estimate

S — new SettingsViewModel.kt (~30 LOC) + picker dialog composable (~40 LOC, private in SettingsScreen.kt or its own file) + SettingsScreen.kt rewiring (~15 LOC: VM injection, row tap handler, dialog open-state, drop the themeMode parameter) + MainActivity.kt Settings-route rewire (~5 LOC) + AppModule.kt 1-line Koin add + new SettingsViewModelTest.kt (~40 LOC). ~90 LOC production.

Split from #74. Builds on #86.

[ilmoniemi]

🤖 Product Owner — creates structured issues

po agent has completed work on this ticket.

Agent output (click to expand)

Refined #87 against the actual code state from #86 (now in `main`). Key changes from the previous body:

- **Made the `MainActivity` rewire explicit.** Previously AC4 just said "Settings composable becomes a thin state + event consumer" without naming what changed. The Settings route in `MainActivity` currently injects `AppPreferences` directly and passes `themeMode` as a parameter (lines 192–201) — the new AC4 spells out that the route swaps to `koinViewModel<SettingsViewModel>()` and the parameter goes away.
- **Headed off MVI over-engineering.** Explicitly noted that full sealed `SettingsState`/`SettingsEvent` types are NOT required at this slice — just `themeMode: StateFlow<ThemeMode>` + `onSelectTheme(mode)` callback. The existing screen is a plain function; a developer reading "thin MVI consumer" could waste turns building full sealed types.
- **Flagged the existing `ThemeMode.label()` extension** at `SettingsScreen.kt:266` so the architect either promotes or duplicates intentionally rather than writing a third copy of the `when` block.
- **Folded the old AC4 + new MainActivity AC into one** — previous wording would have produced 6 ACs (red-line is >5). Now at 5.
- **Updated "Depends On"** from "sibling plumbing ticket must land first" to "✅ #86 (merged in 2cd2c85)" so the architect doesn't go searching.

Size stays `S` (~90 LOC, 2 new files + 1 substantially-edited + 2 trivial edits — under the 3-file red line on "substantially-edited"). No `security-sensitive` label (local UI/preference state, no auth/crypto/network). The dispatcher will add `ready:po` and advance the ticket to In Architecture.

Ready for human review. Move to the next column when approved.

[ilmoniemi]

🤖 System Architect — defines Go interfaces, data flows, concurrency patterns

architect agent has completed work on this ticket.

Agent output (click to expand)

Spec written and committed to `feature/87`.

**Sizing decision:** S, no split. ~90 production LOC across 4 production files (`SettingsViewModel.kt` new, `ThemePickerDialog.kt` new, `SettingsScreen.kt` modified, `MainActivity.kt` minor rewire, `AppModule.kt` 1-line add) plus `SettingsViewModelTest.kt` new. One new exported type (`SettingsViewModel`). No edit fan-out — both `themeMode` parameter and direct `AppPreferences` injection at the Settings route have exactly one consumer each. No branch-overlap with sibling in-flight features.

**Key design decisions:**
- Dialog shape: M3 `AlertDialog` with OK/Cancel (over tap-to-commit) — matches AC language and avoids surprise app-wide theme flips on accidental taps.
- `ThemePickerDialog` in its own file under `ui/settings/` (SettingsScreen.kt is already ~290 lines).
- `ThemeMode.label()` promoted from `private` to `internal` in `SettingsScreen.kt`, **not** moved into `data/preferences/` — keeps UI strings out of the data layer (Compose-Multiplatform walk-back boundary).
- `SettingsViewModel` stays thin: `themeMode: StateFlow<ThemeMode>` via `stateIn(WhileSubscribed(5_000L))` + `fun onSelectTheme(mode)`. No sealed `SettingsState` / `SettingsEvent` — deferred per ticket scope.
- VM tests use the real `AppPreferences` + `TemporaryFolder` rig from `AppPreferencesTest` (no fake — the VM is too thin to be worth stubbing around).

Ready for human review. Move to the next column when approved.