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`.

hive-c0re/src/forge/pr_merge.rs

@@ -1,5 +1,5 @@
 //! PR-based config-flow merge primitives — the forge-side mechanics
-//! hive-c0re's approve-handler (`run_merge_config_pr`) orchestrates to
+//! hive-c0re's deploy apply node (`actions::run_deploy_apply`) orchestrates to
 //! land an operator-approved config PR. Part of the operator trust
 //! boundary; moved verbatim from the `forge` module root.
 
@@ -15,7 +15,7 @@ use super::{CONFIG_ORG, api, core_token, forge_git_url};
 // The dashboard-approve-driven flow has hive-c0re verify an operator-approved
 // config PR, then land it: fast-forward-merge the verified sha into the
 // protected default branch via the forge merge API (= the merge). These fns are
-// the forge-side mechanics the c0re approve-handler (`run_merge_config_pr`)
+// the forge-side mechanics the c0re deploy apply node (`run_deploy_apply`)
 // orchestrates; the orchestration fetches the verified sha into the agent's
 // applied repo (for the eval-verify) before calling `merge_config_pr_ff`. The
 // core token is sourced internally (`core_token`), never passed in. `repo` is

hive-c0re/src/forge/repos.rs

@@ -907,7 +907,7 @@ async fn apply_operator_branch_protection(repo: &str, token: &str) -> Result<()>
 /// - **`main` is never directly pushable** — no push is enabled on the
 ///   protected branch, so neither the agent (a write collaborator) nor
 ///   hive-c0re can `git push` it. It only advances via the config-PR merge
-///   handler (`run_merge_config_pr`), which fast-forward-*merges* the reviewed
+///   node (`actions::run_deploy_apply`), which fast-forward-*merges* the reviewed
 ///   head through the forge merge API (`Do=fast-forward-only`,
 ///   `head_commit_id` pinned to the reviewed sha).
 /// - **merge is whitelisted to `core`** — only hive-c0re can merge a config PR;

hive-c0re/src/lifecycle/setup.rs

@@ -71,7 +71,7 @@ async fn ensure_applied_remote(proposed_dir: &Path, name: &str) -> Result<()> {
 /// proposed's initial commit in via `git fetch`, tag it `deployed/0`.
 /// This is the *only* time hive-c0re reads from `proposed` for an
 /// agent — subsequent config changes are fetched from the reviewed
-/// forge PR head at merge time (see `actions::run_merge_config_pr`).
+/// forge PR head at merge time (see `actions::run_deploy_apply`).
 ///
 /// `proposed_dir` is `None` on rebuild paths where the repo already
 /// exists — we just verify it's the right shape and bail otherwise.

hive-c0re/src/socket_server/config_approvals.rs

@@ -89,7 +89,7 @@ pub(super) fn handle_request_update_meta_inputs(
 /// dashboard shows the pending card immediately.
 ///
 /// The PR head sha is stored as `fetched_sha` on the approval row — the
-/// "reviewed sha" the approve handler (`run_merge_config_pr`) drift-gates
+/// "reviewed sha" the deploy's `MergeVerify` node drift-gates
 /// against before doing anything irreversible. This does NOT fetch the commit
 /// into the applied repo at submission time (that happens inside the approve
 /// handler, step 2, after the drift check). No flake pre-flight either —