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/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