UI-05: rebuild Record screen as the Map HUD (design north star)

Replaces the scrolling stats-card layout with the full-bleed Map HUD:
UI-04's draggable/resizable HUD widgets float over UI-01's shared
background map (full opacity on this tab), and the old Pause/Stop/Resume/
Discard buttons become full-bleed, icon-only segments matching the
mockup's tertiary-container/error-container colors exactly. The idle
state keeps its prior compact layout deliberately -- HUD widgets only
appear once a ride exists, preserving the existing "a resting screen
must not look like a ride going nowhere" guarantee rather than
reinterpreting it.

State-machine logic (ticker, wakelock, speed subscription, error
handling) is untouched; every pre-existing record-screen test passed
unchanged against the rebuilt screen. Added tests that actually tap
Start/Pause/Stop and verify engine state changes, confirm HUD widgets
render over the map rather than replacing it, and verify the
mounted-mode speed digit's real contrast ratio against GlassPanel's
translucent surface specifically (the ticket's own named risk).

Corrects a UI-04 mistake found while implementing this ticket: the HUD's
default four metrics were ordered Speed/Distance/Elapsed/Max Speed, a
guess made before reading the actual Map HUD mockup HTML closely. The
real fixed row is Speed/Avg Speed/Dist/Time -- reordered HudMetric to
match and updated every test that asserted the old order.

Adds PulsingLocationMarker (UI-03) to RideMap's live usage via a new
showLocationMarker flag, and explicit tertiaryContainer/errorContainer
tokens to ripprColors so the control bar matches the design system's
literal values rather than an auto-derived tonal palette.

Verified end-to-end on a real emulator: Start, Pause, Resume, and Stop
all correctly drive the trip state machine with the full live map behind
everything. A lengthy false alarm during this verification (taps
appearing to do nothing) turned out to be a screenshot-scale
mis-measurement on the verification side, not an app defect -- resolved
by sampling pixel colors directly from the raw screenshot to find the
control bar's true on-screen position.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Xki7YAcc2TiN2PRZJ2tXr

lib/src/ui/components/ride_map.dart

@@ -27,6 +27,7 @@ import '../../domain/models.dart';
 import '../../geo/geo.dart' as geo;
 import '../../tiles/tile_config.dart';
 import '../theme.dart' show ripprRadiusLarge;
+import 'pulsing_location_marker.dart';
 import 'skeleton_map_layer.dart';
 
 export '../../tiles/tile_config.dart';
@@ -57,6 +58,7 @@ class RideMap extends StatefulWidget {
     this.fill = false,
     this.showEmptyLabel = true,
     this.skeletonMode = false,
+    this.showLocationMarker = false,
   });
 
   final List<TrackPoint> points;
@@ -92,6 +94,11 @@ class RideMap extends StatefulWidget {
   /// following at all.
   final bool follow;
 
+  /// UI-05: draws a `PulsingLocationMarker` at the latest point -- only meaningful for
+  /// the live shell background (paired with [follow]), never for a finished ride's
+  /// static playback, where there is no "current position" to mark.
+  final bool showLocationMarker;
+
   @override
   State<RideMap> createState() => _RideMapState();
 }
@@ -258,6 +265,21 @@ class _RideMapState extends State<RideMap> with WidgetsBindingObserver {
               tileProvider: widget.tileProvider,
             ),
           PolylineLayer(polylines: polylines),
+          if (widget.showLocationMarker && hasPoints)
+            MarkerLayer(
+              markers: [
+                Marker(
+                  key: const Key('location-marker'),
+                  point: ll.LatLng(
+                    widget.points.last.latitude,
+                    widget.points.last.longitude,
+                  ),
+                  width: 40,
+                  height: 40,
+                  child: const PulsingLocationMarker(),
+                ),
+              ],
+            ),
           const TileAttribution(),
         ],
       ),