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.