feat(ui): map canvas follows light/dark theme; fix invisible gear control

The map view now selects a DARK_THEME or LIGHT_THEME palette from the
resolved app theme and threads it through every primitive builder, so
the canvas, planets, ship groups, cargo routes, battle/bombing markers,
fog, reach + selection rings, pending-Send tracks, and the pick overlay
all switch with the rest of the chrome. A theme flip remounts the
renderer preserving the camera — Pixi bakes the background at init and
every primitive bakes its colour at build, so a live re-tint is not
possible on the same instance.

This also fixes the reported bug: the gear-popover trigger and the
loading overlay hardcoded a dark navy background, so in light theme the
gear was invisible (dark icon on dark chip) until hover flipped it to a
white chip. Both now use the --color-surface-overlay token and read
correctly in both themes.

The light palette mirrors the dark one role-for-role, darkened /
saturated for contrast on a light background while keeping the incoming,
battle, and bombing accents vivid. The values are a first pass meant to
be refined during the F8 manual-QA loop.

Removes the now-dead "Phase 35" references from the code and lifts the
map-recoloring prohibition from the design-system / renderer docs; the
battle scene stays a fixed-palette data-viz surface.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

ui/docs/design-system.md

@@ -94,12 +94,20 @@ them in sync.
   stay literal `rgba(…)`. They sit over arbitrary content, not a themed
   surface, so a surface token would be wrong; there is no `--color-scrim`
   until a third caller justifies one.
-- Data-visualisation surfaces keep a fixed palette. The battle scene
+- Data-visualisation surfaces define their palette in code, not via CSS
+  tokens, because they paint to a canvas / SVG instead of themed DOM.
+  The WebGL map canvas ships two palettes — `DARK_THEME` and
+  `LIGHT_THEME` in [`src/map/world.ts`](../frontend/src/map/world.ts) —
+  and follows the resolved app theme like the rest of the chrome:
+  `active-view/map.svelte` selects the palette from `theme.resolved` and
+  remounts the renderer on a theme flip (Pixi bakes the background and
+  every primitive colour at build time, so a live re-tint is not
+  possible; the remount preserves the camera). The battle scene
   (`battle-player/battle-scene.svelte`) is a self-contained SVG
-  visualisation — like the WebGL map canvas — and stays dark in both
-  themes; its only themed neighbours are the surrounding chrome
-  (`battle-viewer.svelte`). Re-theming a viz surface for light is a
-  dedicated design task, not a token swap.
+  visualisation that still keeps a single fixed dark palette in both
+  themes — re-theming it for light is a separate design task — and its
+  only themed neighbours are the surrounding chrome
+  (`battle-viewer.svelte`).
 - Spacing-scale adoption is gradual — colour tokens are the priority;
   existing one-off paddings are migrated opportunistically, not churned
   en masse.
@@ -113,8 +121,9 @@ battle, mail, toasts). The whole app switches coherently between light
 and dark from a single token change.
 
 The only remaining literal colours are the documented exceptions above:
-the battle-scene data-viz palette, the overlay scrims, and the
-directional / deliberate drop shadows.
+the canvas data-viz palettes (the theme-aware map palette and the fixed
+battle-scene palette, both defined in code rather than as tokens), the
+overlay scrims, and the directional / deliberate drop shadows.
 
 The default theme is **`system`** — it follows the OS light/dark
 preference; users can pin light or dark via the account-menu picker.

ui/docs/renderer.md

@@ -75,11 +75,23 @@ overrides them.
 
 ## Theme
 
-A single dark theme is implemented. The theme is a record of default
-colours; primitives whose `style` omits a colour fall back to the
-theme. Runtime theme switching is not implemented — light/dark and
-the materialise-on-theme-change cycle are deferred to the
-finalization plan ([../PLAN-finalize.md](../PLAN-finalize.md)).
+A `Theme` is the renderer's full colour palette: the canvas background
+and fog veil, the generic fallbacks for primitives whose `style` omits
+a colour, and the semantic colours every primitive builder paints with
+(planets, ship groups, cargo routes, battle / bombing markers, reach +
+selection rings, pending-Send tracks, and the pick-mode overlay). Two
+palettes ship in `src/map/world.ts` — `DARK_THEME` and `LIGHT_THEME` —
+and the builders take the active palette so the whole canvas follows
+the user's light / dark choice.
+
+`active-view/map.svelte` selects the palette from `theme.resolved`
+(`$lib/theme/theme.svelte.ts`) and threads it into `reportToWorld`, the
+overlay builders, and `createRenderer({ theme })`. A theme flip is
+handled by a remount that preserves the camera: Pixi bakes the
+background at `Application.init` and every primitive bakes its colour
+at build time, so the palette cannot be swapped live on an existing
+instance. The debug playground (`routes/__debug/map`) omits the option
+and keeps the `DARK_THEME` default.
 
 ## Hit-test
 
@@ -335,9 +347,9 @@ scanner / visibility coverage:
 - An empty list destroys the existing fog rectangles and mask.
 - A non-empty list rebuilds a single viewport-level `fogLayer` (a
   sibling below the nine torus copies). `fogPaintOps` returns an
-  ordered op list — one world-sized rectangle filled with `FOG_COLOR`
-  (two shades lighter than the dark theme background) plus one circle
-  per visibility circle. The renderer draws the rectangle ops into
+  ordered op list — one world-sized rectangle filled with the active
+  palette's `fog` colour (a faint shade off the theme background) plus
+  one circle per visibility circle. The renderer draws the rectangle ops into
   `fogLayer` and collects the circle ops into a single `Graphics` set
   as `fogLayer`'s **inverse stencil mask**
   (`setMask({ mask, inverse: true })`), so the fog shows everywhere