feat(banner): per-campaign colour overrides and urgent alerts

Non-default campaigns gain an optional colour override (background / text /
link) in two sets — one for every theme, one for the dark theme only — and an
"urgent" flag.

- Colours ride profile.get as six trailing FlatBuffers strings on
  BannerCampaign (backward-compatible). The client resolves the cascade
  (dark <- dark ?? all, light <- all) per rendered theme and derives the strip
  border from the background in JS (no CSS color-mix, for the old Android
  WebView floor); AdBanner applies them as inline vars scoped to the strip.
- Urgent is resolved entirely server-side: while any enabled, in-window urgent
  campaign exists, computeActiveSet returns only the urgent campaigns and
  bannerFor skips the eligibility gate — so a system notice reaches every viewer
  (paid / hint-holding / no_banner included) and preempts the ordinary feed. No
  wire field; it appears on each viewer's next profile.get.
- Admin console (/_gm/banners): native colour pickers + a live light/dark
  preview of the strip, and an urgent toggle. The default campaign stays plain,
  enforced by the service and a DB CHECK.

Migration 00009 is additive (nullable colour columns + a bool default +
all-or-nothing / hex / default-plain CHECKs) — expand-contract, rollback-safe.

Docs: ARCHITECTURE §10, UI_DESIGN, FUNCTIONAL (+ru). Tests: ads unit (urgent
preempt + colour validation), codec + resolver unit, gateway transcode, and
integration (colour round-trip + urgent bypass against real Postgres).

docs/UI_DESIGN.md

@@ -315,6 +315,19 @@ left. A **viewport size change** (e.g. a portrait↔landscape rotation) re-measu
 operator-set (`/_gm/banner-settings`). Under **reduce-motion** the fades collapse to an instant swap
 and a long message does not scroll.
 
+**Per-campaign colours.** A campaign may override the strip's colours (background, text, link). The
+engine carries the current message's campaign colours to the host, and `AdBanner` resolves them for
+the **rendered theme** (`lib/bannerColors`: dark ← dark-set ?? all-set, light ← all-set) and applies
+them as inline CSS variables scoped to `.ad` (`--ad-bg`, `--text-muted`, `--accent`, and a derived
+`--ad-border`) — so an override never leaks past the strip, and a campaign with no override keeps the
+neutral tokens. The border is computed from the background in JS (a luminance-aware nudge toward
+black/white — no CSS `color-mix`, which the old Android WebView floor lacks), matching the admin
+console's live preview. The resolution re-runs when the theme flips (a `[data-theme]` /
+`prefers-color-scheme` observer), so switching light↔dark repaints an overridden strip at once. An
+**urgent** campaign has no client-specific styling — it simply arrives (with its colours) as the only
+campaign in the feed; the preempt-and-show-everyone behaviour is entirely server-side (ARCHITECTURE
+§10).
+
 ## Result / status iconography (`lib/result.ts`)
 
 Lobby rows show two lines (opponents, then result + score) with a large place-based emoji