feat: task 2.1 MapView singleton + mapReady gate

- pnpm add maplibre-gl + -D @types/geojson.
- src/map/core/styles.ts: defaultStyle (OSM raster bootstrap; 2.2
  replaces with the basemap-switcher descriptor table).
- src/map/core/map-view.tsx: module-level Map singleton lazily created
  on first <MapView> mount, attached to a class="trm-map-host" detached
  <div> that React refs append/remove on mount/unmount. Style-data
  lifecycle flips mapReady false on every styledata event, polls
  loaded() at 33ms intervals, flips ready true once the style is
  loaded — the canonical MapLibre style-swap dance.
- Exports getMap()/getMapReady()/subscribeMapReady()/useMapReady (via
  useSyncExternalStore for SSR-safe + concurrent-safe reads). getMap()
  throws if called pre-mount; the explicit failure mode beats a
  null-able top-level export.
- src/routes/_authed/monitor.tsx: new /monitor route, full-viewport
  <MapView /> for 2.1 (no children — subsequent tasks plug in here).
- src/routes/_authed/index.tsx: home-page card now links to /monitor.
- eslint.config.js: override for src/map/** + src/live/** disables
  react-refresh/only-export-components. Same pattern as the existing
  overrides for shadcn primitives and route files.

Deviation: spec sketched a top-level `map` constant export; implemented
as `getMap(): MapLibreMap` (a function) so the singleton stays lazy
until <MapView> mounts. Top-level constant would either force eager
init (breaks SSR/tests) or be nullable (footgun). The function form
throws a clear error if called pre-mount.

Bundle: /monitor lazy chunk is 1MB raw / 274KB gzipped (MapLibre + CSS).
Other routes unaffected. Vite chunk-size warning is harmless.

.planning/phase-2-live-map/06-map-trails.md

@@ -9,7 +9,7 @@
 
 Render the trailing path of every (or only the selected) device as a polyline. Reads from the per-device ring buffer in the position store (2.4 capped at 200 points). Visible as a thin line behind the moving marker — operators see "where this racer has been in the last few minutes."
 
-After this task lands, the live map shows motion *history*, not just current position. That's what makes "live tracking" feel live.
+After this task lands, the live map shows motion _history_, not just current position. That's what makes "live tracking" feel live.
 
 ## Deliverables
 
@@ -59,7 +59,11 @@ The third arg to `addLayer` puts the line layer below the position symbols; trai
 ### Feature builder — flat colour per device
 
 ```ts
-function buildTrailFeature(deviceId: string, points: PositionEntry[], device?: Device): Feature | null {
+function buildTrailFeature(
+  deviceId: string,
+  points: PositionEntry[],
+  device?: Device,
+): Feature | null {
   if (points.length < 2) return null;
   return {
     type: 'Feature',
@@ -111,7 +115,7 @@ useEffect(() => {
 
 ### Speed-coloured per-segment (deferred decision)
 
-Traccar's replay mode renders one line *segment* per consecutive position pair, coloured by the second point's speed. For live trails this would mean N-1 features per device per update — heavier but visually richer. Operators glance at colour to read "fast / slow / stopped."
+Traccar's replay mode renders one line _segment_ per consecutive position pair, coloured by the second point's speed. For live trails this would mean N-1 features per device per update — heavier but visually richer. Operators glance at colour to read "fast / slow / stopped."
 
 If we decide to ship this in v1: replace `LineString` with multiple two-point `LineString`s and colour per segment. The setData payload grows; the line layer's `'line-color'` becomes `['get', 'segmentColor']` instead of the device's flat colour.
 
@@ -136,7 +140,7 @@ If operators want a longer-trail mode: a slider in the prefs (`50 / 200 / 500 /
 - [ ] With the dogfood seed and synthetic positions, `/monitor` shows a polyline trailing each device as it moves.
 - [ ] Switching the trail-mode toggle (none / selected / all) immediately changes which trails render. None → empty layer. Selected → only the selected device. All → every device.
 - [ ] Trail follows the device's most recent N positions; old points fall off the front as new ones append (verify trail is always exactly the configured length once steady-state).
-- [ ] Trails sit *underneath* markers (verifiable visually — markers paint over the polyline).
+- [ ] Trails sit _underneath_ markers (verifiable visually — markers paint over the polyline).
 - [ ] Style swap → trails reappear after the basemap change.
 - [ ] No `setData` warnings (e.g. coordinate-array mismatch).