Per-session owner of one in-flight agent run, decoupled from the LiveView.

The web run used to be a bare Task that sent events straight to the LiveView pid captured when the run started. A websocket reconnect spawns a new LiveView process (new pid), so the in-flight run kept sending to a dead process — the user saw streaming freeze and had to reopen the session.

RunServer fixes that by owning the run itself. It is named by the stable session id ({:via, Registry, ...}), survives LiveView reconnects, and:

• owns the run Task and accumulates just enough live state to re-render a mid-run view (stream_text, current_action, a paused ask_user question, the streaming? flag);
• lets any number of LiveViews attach/2 — subscribe-then-snapshot in one call, then receive the same {:athena, _} / {:athena_done, _} / {:athena_error, _} / {:athena_ask_user, _} messages the LiveView's existing handle_info clauses already expect;
• routes a user's ask_user answer back into the blocked run via the stable channel (answer/3), so the reply survives a reconnect;
• durably persists the final answer (Sessions.persist_run_result/3) the moment the run finishes — works even with zero LiveViews attached.

Supervision & naming

Started on demand under ExAthena.Web.RunSupervisor (a DynamicSupervisor) with restart: :temporary, named {:via, Registry, {ExAthena.Web.RunRegistry, session_id}}. Both the registry and supervisor are started by the mix athena.web task (web-only).

Mirrors the ExAthena.Orchestrator.Coordinator pattern; subscribe/snapshot fan-out is plain send/2 (host-agnostic — no Phoenix.PubSub dependency).