UI redesign: 8 tickets from the Stitch export analysis

Same shape as docs/v3/: Goal/Context/Design/Implementation/Acceptance/Tests/Risks/Out-of-scope, written before implementing.

UI-01: persistent 4-tab shell (StatefulShellRoute) replacing the current push/pop stack rooted at Record, with a single shared background map dimmed behind every tab and no header anywhere.
UI-02: animated skeleton map for the no-cache/no-network case, since the map is now a permanent background presence rather than opt-in per screen.
UI-03: shared GlassPanel/FloatingPill/PulsingLocationMarker component kit.
UI-04: draggable, resizable HUD telemetry widgets with a Settings visibility toggle -- split out from the screen redesign itself since it's a genuinely separate piece of engineering (a small widget-layout system, not a reskin).
UI-05: Map HUD/Record screen redesign -- the design north star every other screen ticket restyles toward.
UI-06: Plan & Route Planning -- correct in principle, explicitly restyled toward UI-05 rather than copying the Stitch export's drifted styling.
UI-07: Rides History -- live dimmed map background (not the mockup's static image), search/filter, real per-ride map thumbnails, and real distinct summary stats (fixing the export's 4-identical-cards generation artifact).
UI-08: theme migration to Modern Professional Dark, superseding V3-16's safety-orange direction.

README documents the dependency order, and two categories worth keeping separate: what was named explicitly by the person commissioning this (map-on-every-tab, no header, offline skeleton, customizable HUD) versus what the mockups themselves got inconsistent (nav icon count, duplicate summary cards, wrong active-tab highlight) and should not be copied as intentional.

docs/ui-redesign/UI-07-rides-history.md

@@ -0,0 +1,84 @@
+# UI-07 — Rides History redesign
+
+**Depends on** UI-01, UI-03 · **Size** M · **Status** Not started
+
+## Goal
+Rebuild the Trips list as "Rides History": a dimmed live map background (per UI-01, not
+a static image), a search bar, and richer ride cards with a real route-thumbnail map —
+restyled to Map HUD's (UI-05) established colors/icons, not the Stitch export's mockup
+styling.
+
+## Context
+Today's `TripsScreen` is a plain `ListView` of `_TripTile`s (icon, name, one-line
+subtitle) over a solid background, reached by pushing off Record. The mockup adds a
+search bar, a filter button, a summary-stats row, and cards with an actual map-thumbnail
+image per ride. By explicit instruction, the background here is the same live map every
+other tab has (dimmed), not the mockup's static blurred screenshot — see UI-01.
+
+**Generation artifact to fix, not copy:** the mockup's summary row is four identical
+"Total Dist: 482 KM" cards. This ticket defines real, distinct summary stats.
+
+## Design
+- **Background:** UI-01's shared dimmed map, same as Settings and Plan get when not the
+  active-content tab.
+- **Search + filter:** a text field over ride name/date, plus a filter affordance (by
+  activity type — V3-01 already has this data — and/or date range). Filtering logic is
+  new; nothing today searches or filters the trips list.
+- **Summary row:** real distinct stats — total distance, total moving time, ride count,
+  and one more genuinely useful figure (e.g. average speed across all rides, or longest
+  ride) rather than repeating one number four times. Computed from existing `Trip`
+  aggregate columns already stored on every completed ride — no new data needed, only a
+  query across all of them.
+- **Ride cards:** title, date, and a distance/time/avg-speed stat row (matching the
+  mockup), plus a **real map thumbnail** — a small, non-interactive `RideMap` (or a
+  lightweight static rendering of the stored path) rather than a stock image, since we
+  actually have the ride's own path data, unlike the mockup's placeholder photos.
+- **Colors/icons:** Map HUD's palette and icon fill-states, per the design north star —
+  not the mockup's card-specific styling choices (e.g. the third card's grayscale/
+  reduced-opacity treatment, which reads as an arbitrary "older ride" decoration with no
+  defined rule — drop it unless a real rule for it is specified).
+
+## Implementation
+1. Rebuild `TripsScreen`'s background to sit over UI-01's dimmed shared map instead of a
+   plain scaffold background.
+2. Add search (text query against `Trip.name`/date) and filter (activity type at
+   minimum, reusing V3-01's `Activity` enum and `activityIcon`/`activityLabel` helpers).
+3. Add a summary-stats query/provider computing totals across `watchCompletedTrips()`
+   (or a dedicated aggregate query if computing it client-side over a large ride history
+   becomes a real cost — measure before optimizing).
+4. Rebuild `_TripTile` as a card with a small live/static `RideMap` thumbnail (reusing
+   the existing `RideMap` widget at a small size and non-interactive, rather than
+   building a second map-rendering path) plus the distance/time/avg-speed row.
+5. Confirm this screen's tab identity/name in the nav bar — "Rides" (mockup's label) vs.
+   "History" vs. keeping "Rides" as used elsewhere in the codebase already (V3-07's
+   Routes screen already uses "Rides" as the trips-tab label on the record screen) —
+   match whatever UI-01's nav bar ships with.
+
+## Acceptance criteria
+- [ ] Background is the shared live map (dimmed), not a static image
+- [ ] Search narrows the list by name/date
+- [ ] Filter narrows the list by activity type
+- [ ] Summary row shows four distinct, real statistics, not one number repeated
+- [ ] Each ride card shows an actual thumbnail of that ride's own path, not a stock photo
+- [ ] Merge/delete/rename actions from today's `TripsScreen` still work
+- [ ] Colors and icon fill-states match Map HUD, not the Stitch export's card styling
+
+## Tests
+- Widget: search filters the visible list correctly
+- Widget: filter-by-activity narrows correctly
+- Unit: summary-stats aggregation matches a hand-computed total over a fixed set of
+  seeded trips
+- All existing `trips list` widget tests (empty state, newest-first ordering, active-ride
+  exclusion, merge-at-exactly-two-selections, delete) updated to the new layout and still
+  passing
+
+## Risks
+- Rendering a small `RideMap` thumbnail per card in a long list could be a real
+  performance cost (many simultaneous `FlutterMap` instances) — consider a lightweight
+  static polyline-on-canvas rendering instead of a full interactive map per thumbnail if
+  this proves too expensive; measure with a real ride history of realistic length before
+  deciding.
+
+## Out of scope
+Any change to trip data, merge, or split logic (V3-10) — presentation and search/filter
+only.