ui/phase-27: battle viewer (radial scene, playback, map markers)

Engine wire change: Report.battle switched from []uuid.UUID to
[]BattleSummary{id, planet, shots} so the map can place battle
markers without N extra fetches. FBS schema + generated Go/TS
regenerated; transcoder + report controller updated; openapi
adds the BattleSummary schema with a freeze test.

Backend gateway forwards engine GET /api/v1/battle/:turn/:uuid as
/api/v1/user/games/{game_id}/battles/{turn}/{battle_id} (handler
plus engineclient.FetchBattle, contract test stub, openapi spec).

UI:
- BattleViewer (lib/battle-player/) is a logically isolated SVG
  radial scene that consumes a BattleReport prop. Planet at the
  centre, races on the outer ring at equal angular spacing, race
  clusters by (race, className) with <class>:<numLeft> labels;
  observer groups (inBattle: false) are not drawn; eliminated
  races drop out and survivors re-distribute on the next frame.
- Shot line per frame: red on destroyed, green otherwise; erased
  on the next frame. Playback controls: play/pause + step ± +
  rewind + 1x/2x/4x speed (400/200/100 ms per frame).
- Page wrapper (lib/active-view/battle.svelte) loads BattleReport
  via api/battle-fetch.ts; synthetic-gameId prefix routes to a
  fixture loader, otherwise REST through the gateway. Always-
  visible <ol> text protocol satisfies the accessibility ask.
- section-battles.svelte links every battle UUID into the viewer.
- map/battle-markers.ts: yellow X cross of 2 LinePrim through the
  corners of the planet's circumscribed square (stroke width
  clamps from 1 px at 1 shot to 5 px at 100+ shots); bombing
  marker is a stroke-only ring (yellow when damaged, red when
  wiped). Wired into state-binding.ts; click handler dispatches
  battle clicks to the viewer and bombing clicks to the matching
  Reports row.
- i18n keys for the viewer in en + ru.

Docs: ui/docs/battle-viewer-ux.md, FUNCTIONAL.md §6.5 + ru
mirror, ui/PLAN.md Phase 27 decisions + deferred TODOs (push
event, richer class visuals, animated re-distribution).

Tests: Vitest unit (radial layout + timeline frame builder +
marker stroke formula + marker primitives), Playwright e2e for
the viewer (Reports link → viewer, playback step, not-found),
backend engineclient FetchBattle (200 / 404 / bad input), engine
openapi freezes (BattleReport, BattleReportGroup,
BattleActionReport, BattleSummary, Report.battle items).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/FUNCTIONAL.md

@@ -657,7 +657,7 @@ in `runtime_records.turn_schedule`. The backend scheduler
 - After a failed tick (`engine_unreachable` /
   `generation_failed`): the lobby's `OnRuntimeSnapshot` flips the
   game from `running` to `paused` and publishes a `game.paused`
-  push event (see §6.5). The order handlers reject with HTTP 409
+  push event (see §6.6). The order handlers reject with HTTP 409
   + `code = game_paused` until an admin resume succeeds.
 
 `force-next-turn` (admin) schedules a one-shot extra tick that
@@ -686,7 +686,53 @@ are exposed in a sticky table of contents (a `<select>` on mobile)
 and the scroll position is preserved across active-view switches
 via SvelteKit's `Snapshot` API.
 
-### 6.5 Side effects
+The Bombings section is a flat read-only table — one row per
+bombing event, columns for `attacker`, `attack_power`, `wiped`
+state and the post-bombing resource snapshot. The Battles section
+is a list of links into the Battle Viewer (see [§6.5](#65-battle-viewer)).
+
+### 6.5 Battle viewer
+
+The Battle Viewer is a dedicated view that replaces the map and
+renders one battle at a time. Entry points:
+
+- A row in the Reports view's Battles section (link with the
+  current turn pinned via `?turn=`).
+- A battle marker on the map (yellow cross drawn through the
+  corners of the square that circumscribes the planet circle;
+  stroke width scales with the protocol length).
+
+The viewer is a logically isolated component that consumes a
+`BattleReport` (shape per `pkg/model/report/battle.go`). The page
+loader (`ui/frontend/src/lib/active-view/battle.svelte`) fetches
+the report through the backend gateway route
+`GET /api/v1/user/games/{game_id}/battles/{turn}/{battle_id}`,
+which forwards verbatim to the engine's
+`GET /api/v1/battle/:turn/:uuid`.
+
+Visual model is radial: the planet sits at the centre, races are
+placed at equal angular spacing on an outer ring, and each race is
+rendered as a horizontal cluster of small ship-class circles
+labelled `<className>:<numLeft>`. Observer groups (`inBattle:
+false`) are not drawn. Eliminated races drop out and the survivors
+re-spread on the next frame.
+
+Each frame is one protocol entry; the shot is drawn as a thin line
+from attacker to defender, red on `destroyed`, green otherwise.
+Continuous playback offers 1x / 2x / 4x speeds (400 / 200 / 100 ms
+per frame), plus play/pause, step ±, and rewind. The accessibility
+text protocol below the scene mirrors the same events line-by-line.
+
+Bombings and battles are intentionally not mixed: bombings remain a
+static table in the Reports view; the bombing marker on the map is
+a thin stroke-only ring around the planet (yellow when damaged, red
+when wiped) and a click scrolls the corresponding row into view.
+
+The current report wire carries a `battle: [{ id, planet, shots }]`
+summary per battle so the map markers know where to anchor without
+fetching every full `BattleReport`.
+
+### 6.6 Side effects
 
 A successful turn generation publishes a runtime snapshot into the
 lobby module, which updates the denormalised view (current turn,
@@ -719,7 +765,7 @@ producer; adding one is purely additive (register the kind in the
 catalog, extend the migration `CHECK` constraint, and call
 `notification.Submit` from the appropriate domain module).
 
-### 6.6 Cross-references
+### 6.7 Cross-references
 
 - Backend ↔ engine wire contract (`pkg/model/{order,report,rest}`):
   [ARCHITECTURE.md §9](ARCHITECTURE.md#9-backend--game-engine-communication).