docs: describe the deploy subtree

Rewrite the approval flow's step 4 as the three phases, with the reason
the rollback state is a git ref, and refresh the coordinator's node
inventory + dispatch table. Fix four doc comments that still pointed at
the deleted `run_merge_config_pr`.

docs/approvals.md

@@ -38,23 +38,33 @@ request.
    comments, CI status) and sees a matching card on the dashboard with a
    "review PR on forge" deep link. They click ◆ APPR0VE (or
    `hivectl approvals approve <id>` on the CLI) once satisfied.
-4. On approve, `run_merge_config_pr`:
-   - re-reads the live PR head and **aborts if it drifted** from the
-     reviewed `fetched_sha` (the submitter must push again, which queues
-     a fresh approval);
-   - fetches that head into the applied repo and **eval-verifies** it —
-     a flake eval on a throwaway checkout. This is the trust gate: it
-     relies on c0re's own eval, not on any in-repo (agent-forgeable)
-     signal like a CI status;
-   - fast-forwards the forge config repo's `main` to the reviewed head
-     (this IS the merge — a `core`-authenticated ff-push, so a moved PR
-     head can't substitute bytes) and marks the PR merged (best-effort;
-     `main` is already there);
-   - runs the shared deploy tail (`deploy_applied_target`): builds under
-     the tag sequence below, and on success `applied/main`
-     fast-forwards to the reviewed commit + the meta lock bumps. On
-     failure, main stays put and the working tree resets to the previous
-     deployed commit.
+4. On approve, a deploy DAG runs three phases under a resource-holding
+   `DeployWindow` root (see *Queue templates* below):
+   - `MergeVerify` re-reads the live PR head and **aborts if it drifted**
+     from the reviewed `fetched_sha` (the submitter must push again,
+     which queues a fresh approval); then fetches that head into the
+     applied repo and **eval-verifies** it — a flake eval on a throwaway
+     checkout. This is the trust gate: it relies on c0re's own eval, not
+     on any in-repo (agent-forgeable) signal like a CI status. Nothing is
+     mutated in this phase, so a rejection here leaves the forge and the
+     applied repo exactly as they were.
+   - `DeployApply` parks the pre-merge `applied/main` in
+     `refs/hyperhive/rollback/<approval-id>`, then fast-forward-merges
+     the reviewed head to the forge config repo's `main` (this IS the
+     merge — a `core`-authenticated ff-merge pinned to the reviewed sha,
+     so a moved PR head can't substitute bytes), and runs the deploy
+     proper (`deploy_applied_target`): ff `applied/main`, two-phase meta
+     deploy, container rebuild. On success it drops the rollback ref and
+     plants `deployed/<id>`.
+   - `DeployTail` runs on **every** outcome, including a cancel-cascade.
+     If the rollback ref survived, the deploy never confirmed good: it
+     rolls `applied/main` back, resyncs the working tree, and aborts the
+     staged meta lock, so the agent stays on its last-good tree. Then it
+     mirrors the config repo (and its new deploy tag) to the forge.
+
+   The rollback state lives in a **git ref, not a local variable**, on
+   purpose: hive-c0re can restart between the apply and the tail, and the
+   tail still has to know what to undo when it does.
 5. `HelperEvent::ApprovalResolved` (and `Rebuilt`) land in the
    **submitting agent's** inbox via `notify_submitter`, carrying both the
    canonical sha and the terminal tag (the approval row carries a
@@ -100,13 +110,12 @@ kind-specific payload carrier.
   approval row. No MCP tool call needed — the forge PR IS the request.
   `commit_ref` stores the **PR number** (decimal), and `fetched_sha` is
   the PR **head sha at queue time** (the "reviewed" sha). On approve,
-  `run_merge_config_pr` re-reads the live PR head and aborts if it
-  drifted from `fetched_sha` (submitter must push again to
-  re-trigger), then fetches that head into the applied repo,
-  eval-verifies it, fast-forwards the forge config repo's `main` to
-  it (the merge), marks the PR merged (best-effort — `main` is
-  already there), and runs the shared deploy tail
-  (`deploy_applied_target`). Never a first spawn.
+  the deploy DAG's `MergeVerify` phase re-reads the live PR head and
+  aborts if it drifted from `fetched_sha` (submitter must push again to
+  re-trigger), then fetches that head into the applied repo and
+  eval-verifies it; `DeployApply` fast-forward-merges the forge config
+  repo's `main` to it (the merge) and runs `deploy_applied_target`;
+  `DeployTail` compensates on failure. Never a first spawn.
 - `Spawn` — direct container creation from the agent's config repo.
   `commit_ref` is empty. Submitted via `HostRequest::RequestSpawn`
   (operator-gated, the `◆ R3QU3ST SP4WN` dashboard button +
@@ -239,8 +248,9 @@ place (it only re-locks when the declared url itself changes), so
 the forge-declared / applied-deployed split is stable.
 
 Per-deploy lock flow (two-phase, owned by
-`actions::run_merge_config_pr` → `deploy_applied_target` →
-`meta::{prepare,finalize,abort}_deploy`):
+`actions::run_deploy_apply` → `deploy_applied_target` →
+`meta::{prepare,finalize,abort}_deploy`, with the abort half moved out
+into `actions::run_deploy_tail`):
 
 1. `meta::prepare_deploy(name)` runs
    `nix flake lock --update-input agent-<n>` without
@@ -254,10 +264,13 @@ Per-deploy lock flow (two-phase, owned by
    <id>")` stages `flake.lock` and commits with
    `deploy <n> deployed/<id> <sha12>`. Meta's git log gains
    one entry per successful deploy.
-4. On failure — `meta::abort_deploy()` runs
-   `git restore flake.lock` so the meta history shows only
+4. On failure — the `DeployTail` node runs `meta::abort_deploy()`
+   (`git restore flake.lock`) so the meta history shows only
    successes; the failure stays as an annotated `failed/<id>`
-   tag in `applied/<n>`.
+   tag in `applied/<n>`. The tail runs on every outcome, so this
+   also covers a hive-c0re restart mid-build: the staged lock is
+   dropped and `applied/main` rolled back from the parked
+   `refs/hyperhive/rollback/<id>`.
 
 Single-phase variants exist for paths without
 rollback semantics: `meta::lock_update_for_rebuild(name)` for
@@ -346,18 +359,22 @@ the approval handler submits a DAG to the global job queue
 
 | `ApprovalKind` | DAG submitted | source |
 |---|---|---|
-| `MergeConfigPr` | `rebuild` (single opaque `ApprovalDeploy` node) | `approval` |
+| `MergeConfigPr` | `rebuild` (`DeployWindow` root + `MergeVerify → DeployApply` + `DeployTail`) | `approval` |
 | `UpdateMetaInputs` | `meta_update` (`MetaLock` + rebuild fan-out) | `approval` |
 | `Spawn` | `spawn` (`Create → WriteDropin → Reconcile`) | `approval` |
 | `InitConfig` | — runs inline (sub-second git seed) | — |
 | `SchedulePrompt` | — runs inline (single sqlite insert) | — |
 
-The DAG carries the originating `approval_id`. The `ApprovalDeploy`
-node runs `run_approval_merge_config_pr` (the two-phase meta deploy
-stays inside `actions.rs`) and fires the matching `HelperEvent::*` via
-`finish_approval` itself; `Spawn` and `UpdateMetaInputs` DAGs resolve
-through `actions::resolve_approval_dag` when the DAG settles terminal
-(a spawn additionally runs the post-spawn forge bookkeeping there).
+The DAG carries the originating `approval_id`, surfaced on the node that
+owns it — for a deploy that's the `DeployWindow` root, so the dashboard
+renders one approval card, not four. **Every** queued kind resolves
+through `actions::resolve_approval_dag` when its DAG settles terminal:
+the deploy's phases are ordinary queue nodes, so the DAG's own terminal
+state is the authoritative outcome. That hook fires the matching
+`HelperEvent::*` via `finish_approval`, derives the `Rebuilt` event's
+terminal tag (verifying the tag actually resolves in the applied repo —
+a pre-merge rejection plants none), posts the failing build log back to
+the config PR, and for a spawn runs the post-spawn forge bookkeeping.
 
 Two visible consequences: