Add live dashboard with SSE job events

Expose /jobs, /dedup, and /events routes backed by a new EventBus that
broadcasts job lifecycle and per-job progress over SSE. Serve a static
dashboard from front/ that lists pending and in-progress jobs, streams
agent activity, and shows completed reviews.

Also add migrate-apply/migrate-generate scripts that load .env, update
the Containerfile to ship the front assets and use the apply script, and
refresh the roadmap.

ROADMAP.md

@@ -11,15 +11,22 @@
 - If a repository has no Dev Container configuration, run its review in a default container based on `debian:stable-slim`.
 - Use `/workspace` as the workspace path for the default container and as the fallback when `workspaceFolder` is not specified.
 
-## 1.3 — Typed action routing — planned
+## 1.3 — Durable jobs & resumption — planned
+
+- Persist review jobs and their progress in PostgreSQL so in-flight work survives a restart and can be resumed instead of being lost.
+- Expose an API to retrieve the list of jobs by state: running, pending, and review done.
+- Stream job events over Server-Sent Events (SSE) so clients see status changes in real time.
+
+## 1.4 — YAML configuration — planned
+
+- Add a YAML configuration file as the primary way to configure Steep, replacing part of the current environment variables.
+- Move non-secret settings such as the model, timeouts, concurrency limit, and sandbox iterations into the file, and keep secrets (API keys, tokens, webhook secret, database URL) in environment variables.
+
+## 2.0 — Typed action routing and implementation requests — planned
 
 - Introduce a type-safe model output for the action Steep should take, such as `Review` or `Implementation`.
 - Route review requests (for example, “@steep, review this PR”) to the existing review flow.
-- Recognize implementation requests (for example, “@steep, rename method `XXX` to `YYY`”) and establish their dispatch path. Execution of implementation requests is planned for 2.0.
-
-## 2.0 — Implementation requests — planned
-
-- Use the typed action from 1.3 to route explicit implementation requests to an implementation workflow.
+- Recognize implementation requests (for example, “@steep, rename method `XXX` to `YYY`”) and route them to the implementation workflow.
 - For a request on an issue, clone the repository from its default branch and implement the requested features on a new branch.
 - For a request on an existing pull request, clone its branch and implement the requested modifications there.
 - When the agent's iteration loop ends, the orchestration layer automatically pushes the resulting changes: it opens a pull request for issue-based work, or updates the existing pull request branch. The agent does not receive or invoke a push tool.
@@ -31,6 +38,11 @@
 - Allow configuring a dedicated model for pull request reviews and another for implementation requests.
 - Route each action type to its configured model, with a clear fallback when only one model is configured.
 
+## 2.2 — Sub-agents — planned
+
+- Let the agent delegate well-scoped parts of a task to sub-agents that run their own iteration loop.
+- Run independent sub-agents in parallel and have the main agent consolidate their results.
+
 ## 3.0 — Autonomous Sentry fixes — planned
 
 - Automatically discover project errors reported by Sentry, without waiting for a user comment.