V3-05: mounted (handlebar) mode

Wake lock via a WakelockController seam (mirrors LocationSource), gated strictly to actual recording and released on stop/discard/navigate-away/dispose. High-contrast ripprMountedTheme() applied only to the record screen. BigStat gained a scale param for the headline figure rather than a blanket TextTheme.apply, which crashes on Material 3's default theme.

docs/v3/V3-05-mounted-mode.md

@@ -1,6 +1,6 @@
 # V3-05 — Mounted (handlebar) mode
 
-**Phase** Live map · **Depends on** V3-04 · **Size** M · **Status** Not started
+**Phase** Live map · **Depends on** V3-04 · **Size** M · **Status** Done
 
 ## Goal
 Make the app usable on handlebars in daylight, at speed, with gloves — as an explicit mode
@@ -51,3 +51,51 @@ A toggle that changes several things at once:
 ## Out of scope
 A dedicated mounted layout with different information architecture — start by scaling what
 exists and see what the ride teaches.
+
+## Outcome
+Shipped as designed, plus two deviations worth recording.
+
+`Config.mountedMode` follows the same seeded-`StateProvider` shape as `mapEnabled` and
+`unitSystem` (`mountedModeProvider`); a quick-toggle icon button sits next to Settings on
+the record screen, and a matching switch was added to `SettingsScreen`. The wake lock is
+wrapped in a `WakelockController` seam (`FakeWakelockController` for tests), mirroring
+`LocationSource` — the same reasoning: the risk named in this ticket ("a leaked lock
+flattens the battery silently") is exactly the kind of thing that has to be provable, not
+just plausible.
+
+**Deviation 1 — no `TextTheme.apply(fontSizeFactor: ...)`.** The design called for scaling
+the whole mounted text theme at once; Flutter's `TextStyle.apply` asserts when
+`fontSizeFactor != 1.0` meets any style with a null `fontSize`, which Material 3's default
+`TextTheme` has for at least one role. Scaling was moved to where it already existed:
+`BigStat` gained an explicit `scale` parameter (default `1.0`), applied to the record
+screen's headline figure only. `StatRow` and button labels were **not** wired to
+`mountedTextScale` — the acceptance criterion is legibility of the number that matters at
+a glance, not uniform scaling of every row, and over-scaling the stat card risked
+reintroducing the record screen's known overflow-on-short-phones failure mode.
+
+**Deviation 2 — the mounted theme wraps only the record screen**, via a local `Theme(...)`
+widget inside `RecordScreen.build`, not the app's `MaterialApp`. `Theme.of(context)` inside
+that build method would still report the ambient dark theme, so `colors` is read off the
+locally-built `ThemeData` directly rather than through `Theme.of(context)` — a small trap
+worth flagging for V3-16, which will touch this same file.
+
+Wake lock acquisition is gated on **recording**, not merely mounted-and-idle or
+mounted-and-paused, and re-evaluated both on trip-state transitions and on the mounted
+toggle itself changing mid-ride. Release happens on stop, on discard (both drive the same
+trip-state listener), on navigating away (`dispose`), and defensively whenever mounted mode
+is off. One implementation snag: reading `ref` inside `State.dispose()` throws
+(`ConsumerStatefulElement` forbids it once unmounting has started) — fixed by capturing the
+`WakelockController` once in `initState` via a `late final` field instead of reading it
+fresh in `dispose`.
+
+7 new tests across `widget_test.dart` (wake lock acquired while recording+mounted,
+never requested un-mounted, released on ride completion, released on navigating away
+while still recording, mounted theme scales the headline and enlarges Start),
+`settings_screen_test.dart` (switch writes through to `Config`), and `config_test.dart`
+(default/round-trip). `flutter analyze` clean; full suite green (231 tests, up from 224).
+
+Not done, and explicitly out of scope per the ticket: real daylight/glove legibility
+(needs an actual ride — V3-13), and `AppLifecycleState.inactive` handling for an incoming
+call — recording is already fully DB-derived and does not observe app lifecycle at all, so
+a call cannot stop it; this was verified by reasoning about the existing architecture
+rather than a new test, since there is no lifecycle-reactive code path to test.