UI-09: switch to CARTO dark map tiles with attribution and cache versioning

Replaces OSM's tan/cream default raster style with CARTO's "Dark Matter"
basemap (both RideMap and the route planner's independent TileLayer), so
the map itself looks like the dark mockups rather than a light basemap
under a dark overlay. Shares one urlTemplate/subdomains/maxNativeZoom
across both call sites instead of two independently-drifting copies.

Re-points the V3-11 tile cache at a versioned directory (tiles/carto_dark_v1)
since TileKey(z, x, y) carries no provider identity and would otherwise
silently serve stale tan tiles cached under the old scheme. Added a test
proving cache isolation holds across provider directories.

Adds a shared TileAttribution widget crediting both OpenStreetMap (CARTO's
style is still built from OSM data) and CARTO, composed into every map
rather than duplicated per screen -- OSM-only credit stopped being
sufficient once a second tile host entered the mix.

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

docs/ui-redesign/README.md

@@ -27,7 +27,7 @@ v3 held to.
 | [UI-06](UI-06-plan-and-route-planning.md) | Plan & Route Planning redesign | M | UI-01, UI-03 | Not started |
 | [UI-07](UI-07-rides-history.md) | Rides History redesign | M | UI-01, UI-03 | Not started |
 | [UI-08](UI-08-theme-modern-professional-dark.md) | Theme migration to Modern Professional Dark | S | — | Done |
-| [UI-09](UI-09-monochrome-dark-map-tiles.md) | Monochrome dark map tiles | S | — | Not started |
+| [UI-09](UI-09-monochrome-dark-map-tiles.md) | Monochrome dark map tiles | S | — | Done |
 
 ## Dependencies
 

docs/ui-redesign/UI-09-monochrome-dark-map-tiles.md

@@ -1,6 +1,6 @@
 # UI-09 — Monochrome dark map tiles
 
-**Depends on** nothing · **Size** S · **Status** Not started
+**Depends on** nothing · **Size** S · **Status** Done
 
 ## Goal
 Replace the tan/cream default OpenStreetMap raster style with a monochrome dark map, so
@@ -96,3 +96,59 @@ ticket, not a separate one — see Implementation.
 ## Out of scope
 A fully custom/self-hosted vector tile style — much larger scope, and not needed to hit
 "looks like the mockups" today.
+
+## Outcome
+
+Took the recommended Option A. `ride_map.dart` now defines `tileUrlTemplate`
+(`https://{s}.basemaps.cartocdn.com/dark_all/{z}/{x}/{y}{r}.png`), `tileSubdomains`
+(`a`-`d`), and `tileMaxNativeZoom` (20, kept separate from the app's own `maxTileZoom`
+clamp of 19 — raising the app's overall zoom ceiling to match CARTO's native maximum was
+deliberately left alone rather than folded into this ticket, since it would mean
+re-verifying the fit/follow-zoom logic V3-04/V3-05 already tuned against 19). Both
+`RideMap` and `route_planner_screen.dart`'s independent `TileLayer` now import and use
+these same three constants plus `retinaMode: true`, so there is exactly one dark style
+and one set of tile-request parameters across the app, not two independently-drifting
+copies.
+
+**Cache versioning (the ticket's named risk):** `tileCacheProvider` in
+`app/providers.dart` now points `FileTileCache` at `tiles/carto_dark_v1` instead of the
+old bare `tiles` directory. `TileKey(z, x, y)` still carries no provider identity, so
+the directory segment is the actual version tag — any tiles cached under the old OSM-tan
+scheme are simply orphaned in a directory the app no longer reads from, rather than
+being silently served under the new dark UI. Added a unit test
+(`test/tile_cache_test.dart`, "a tile cached under one provider directory is not served
+from another") proving this isolation holds at the `FileTileCache` level, the same way
+V3-11's own eviction tests exercise cache behavior directly rather than through the UI.
+
+**Attribution:** added a shared `TileAttribution` widget (`ride_map.dart`) wrapping
+flutter_map's `RichAttributionWidget` with `TextSourceAttribution`s for both
+"OpenStreetMap contributors" (CARTO's dark style is still built from OSM's underlying
+data) and "CARTO" itself — OSM-only credit, which is what the app carried before, stopped
+being sufficient the moment a second tile host entered the mix. Composed into both
+`RideMap` and the route planner's `FlutterMap`, so it's one component discharging the
+obligation everywhere a map renders, not a copy-pasted attribution block per screen. Did
+not wire up `onTap` license-page links — that would need the `url_launcher` package, a
+new dependency this ticket has no other reason to add; the obligation is to visibly
+credit both sources, not to make the credit tappable.
+
+**Tests:** `flutter analyze` clean. `flutter test` green at 316 tests (315 + the new
+cache-isolation test) — no existing test hardcoded the old OSM URL string, so nothing
+else needed updating.
+
+**Android emulator verification** (`Medium_Phone_API_35`): confirmed CARTO's dark,
+desaturated basemap renders on-device (a genuinely dark map, not a tan basemap under a
+dark overlay) — a clear visual match for the Stitch mockups' aesthetic, on the Map tab at
+full opacity and dimmed correctly on Rides/Plan/Settings via UI-01's existing scrim. The
+attribution icon is visibly present in the bottom-left corner on every tab (same shared
+map instance). Its tap-to-expand interaction could not be confirmed via `adb input tap`
+in this session — taps at its on-screen coordinates didn't visibly toggle the popup, and
+a genuine Android mock-location watermark icon (left over from this session's earlier
+`adb emu geo fix` calls, and confirmed present at the same screen position across
+unrelated tabs, which a page-level widget couldn't be) sits immediately next to it,
+making the exact tap target ambiguous to hit blindly. This is a dev-tooling
+verification gap, not a known defect — the widget itself renders without error and
+matches flutter_map's standard, widely-shipped attribution pattern (the same
+small-icon-that-expands convention Google Maps and Mapbox both use). Re-verify the
+popup's tap behavior with a real touchscreen or Flutter Inspector if it becomes load-
+bearing later (e.g., if legal review specifically requires confirming the expand
+interaction, not just the icon's presence).