# Arena gets dedicated battles/contestants tables and replaces the old API-only arena

The Arena feature reuses the dispatcher, the `onTaskTerminal` advance hook, the
streaming→WS-frame pipeline, and the pane pattern from the Orchestrator, but
persists to its **own `battles` + `contestants` tables** rather than the
Orchestrator's `flow_runs`/`flow_steps`. A Battle is not shaped like a flow — it
has two scheduling lanes, per-contestant benchmarks, on-disk results folders, a
two-stage analysis, and cross-examinations — so modelling it as flow steps would
fight the schema. Each Contestant links to a real `tasks` row via `task_id`,
inheriting all worktree/streaming/dispatch machinery. This also **replaces the
earlier v2.0.5 API-only arena** (`POST /api/arena`, `tasks.arena_id`,
select-winner): that feature had no UI and no users, and the new Arena is a
strict superset, so the old routes and the `tasks.arena_id` column are removed
rather than left as a second, competing "arena" concept.

## Consequences

- Analysis and cross-examination run through a small pluggable **Analyzer** seam
  (v1 = default-model two-stage judge). A v2 that drives a Han Orchestrator flow
  as the analyzer slots in behind that seam without a schema change.
- The `arena` pane kind, `ArenaState`, and `battle_*` WS frames are added
  alongside (not folded into) the Orchestrator's, mirroring its patterns.