deploy: gate config merges on ancestry, CAS the applied/main move

A config deploy could silently discard committed agent config. sock's
icon commit carried a full proposal/approved/building/deployed tag set
yet was not an ancestor of `main` — genuinely deployed, then dropped.

Two gaps compounded.

`prepare_applied_target` is documented as "fast-forward applied/main to
target", but `git_update_ref` is `git update-ref <ref> <target>` with no
old-value guard: an unconditional force move. Anything reachable from the
old `main` but not from `target` leaves the branch without a word.

And nothing checked that it *was* a fast-forward. `run_deploy_merge_verify`
asserts exactly one thing about history — that the live PR head still
equals the reviewed sha. That is a drift gate on the *head*; it says
nothing about the *base*. A PR opened from a stale base passes it
unchanged and then rewinds `main` when it lands.

Adds, in the order they run:

- an ancestry gate as step 3 of MergeVerify — the reviewed head must
  descend from `applied/main`, else bail before the irreversible merge.
  It sits after the fetch (the commit has to be local to check
  reachability) and before the eval, so it stays inside the region where
  nothing is mutated and the node is still safely retryable.

- `git_update_ref_cas`, used for the `applied/main` move.
  `git update-ref <ref> <new> <old>` refuses, and leaves the ref alone,
  when the current value is not `old`. The ancestry gate only proves the
  target is safe against the `main` observed *then*; the CAS is what
  keeps that proof true *now*. `run_deploy_apply` already reads
  `prev_main` to park the rollback ref, so that value is threaded in —
  re-reading it inside the callee would reintroduce the race.

`git_is_ancestor` returns `Ok(false)` for exit 1 rather than treating
"not an ancestor" as a failure. Its doc comment notes this is not the
"did this branch land upstream" question: a squash-merge rewrites the
commit, so `--is-ancestor` correctly answers false for a branch whose
contents were merged. Different question, same command.

Tests cover both directions of the ancestry check, and that a stale CAS
both errors *and* leaves the ref where it was — a guard that fails while
still moving the ref would be worse than none.

Not covered here, deliberately: the non-PR apply path also writes `main`
and wants the same treatment. Kept separate to stay reviewable.

hive-c0re/src/lifecycle/git.rs

@@ -168,6 +168,59 @@ pub async fn git_update_ref(dir: &Path, refname: &str, target: &str) -> Result<(
     git(dir, &["update-ref", refname, target]).await
 }
 
+/// Compare-and-swap a ref: move `refname` to `new` only if it currently points
+/// at `old`. `git update-ref <ref> <new> <old>` refuses — leaving the ref
+/// untouched — when the current value differs. That refusal is the whole
+/// difference between "advance this branch" and "overwrite whatever is there".
+///
+/// Prefer this over [`git_update_ref`] whenever the caller already knows the
+/// value it believes the ref holds: a plain `update-ref` that raced another
+/// writer discards the other writer's commits without a word.
+///
+/// # Errors
+///
+/// Returns an error if the ref does not currently point at `old` (the CAS lost)
+/// or if the `git` invocation itself fails.
+pub async fn git_update_ref_cas(dir: &Path, refname: &str, new: &str, old: &str) -> Result<()> {
+    git(dir, &["update-ref", refname, new, old]).await
+}
+
+/// True when `ancestor` is reachable from `descendant` — i.e. moving a branch
+/// from `ancestor` to `descendant` is a genuine fast-forward that discards
+/// nothing.
+///
+/// Not the same question as "did this branch land upstream": a squash-merge
+/// rewrites the commit, so `--is-ancestor` correctly answers `false` for a
+/// branch whose *contents* were merged. This helper compares two commits with
+/// real shared ancestry inside one repo, which is precisely what it decides.
+///
+/// # Errors
+///
+/// Returns an error if `git` fails to run or either revision can't be resolved.
+/// A clean "no, not an ancestor" is `Ok(false)`, not an error.
+pub async fn git_is_ancestor(dir: &Path, ancestor: &str, descendant: &str) -> Result<bool> {
+    let out = git_command()
+        .current_dir(dir)
+        .args(["merge-base", "--is-ancestor", ancestor, descendant])
+        .output()
+        .await
+        .with_context(|| {
+            format!(
+                "git merge-base --is-ancestor {ancestor} {descendant} in {}",
+                dir.display()
+            )
+        })?;
+    match out.status.code() {
+        Some(0) => Ok(true),
+        Some(1) => Ok(false),
+        _ => bail!(
+            "git merge-base --is-ancestor {ancestor} {descendant} failed ({}): {}",
+            out.status,
+            String::from_utf8_lossy(&out.stderr).trim()
+        ),
+    }
+}
+
 /// Delete a ref. The counterpart to [`git_update_ref`] for the bookkeeping
 /// refs a deploy parks in the applied repo (`refs/hyperhive/rollback/<id>`,
 /// which records the pre-merge `main` so the deploy tail can compensate a

hive-c0re/src/lifecycle/mod.rs

@@ -7,8 +7,8 @@ mod setup;
 mod tests;
 
 pub use git::{
-    git, git_command, git_delete_ref, git_read_tree_reset, git_rev_parse, git_tag,
-    git_tag_annotated, git_update_ref,
+    git, git_command, git_delete_ref, git_is_ancestor, git_read_tree_reset, git_rev_parse, git_tag,
+    git_tag_annotated, git_update_ref, git_update_ref_cas,
 };
 pub use host_config::write_dropins;
 pub use setup::{

hive-c0re/src/lifecycle/tests.rs

@@ -91,3 +91,92 @@ async fn setup_proposed_idempotent() {
         "expected exactly one commit after idempotent call"
     );
 }
+
+/// Build a two-commit repo and return `(dir, repo_path, first, second)`.
+async fn two_commit_repo() -> (tempfile::TempDir, std::path::PathBuf, String, String) {
+    let dir = tempfile::tempdir().expect("tempdir");
+    let repo = dir.path().join("proposed");
+    setup_proposed(&repo, "test-agent")
+        .await
+        .expect("setup_proposed");
+    let first = git_rev_parse(&repo, "HEAD").await.expect("rev-parse first");
+
+    std::fs::write(repo.join("second.txt"), "second").expect("write second.txt");
+    git(&repo, &["add", "second.txt"]).await.expect("git add");
+    git(
+        &repo,
+        &[
+            "-c",
+            "user.name=test",
+            "-c",
+            "user.email=test@example.com",
+            "commit",
+            "-m",
+            "second",
+        ],
+    )
+    .await
+    .expect("git commit");
+    let second = git_rev_parse(&repo, "HEAD")
+        .await
+        .expect("rev-parse second");
+
+    assert_ne!(first, second, "second commit did not advance HEAD");
+    (dir, repo, first, second)
+}
+
+/// `git_is_ancestor` answers reachability in both directions. This is the
+/// check that decides whether moving a branch is a real fast-forward or a
+/// rewind that discards commits.
+#[tokio::test]
+async fn is_ancestor_distinguishes_direction() {
+    let (_dir, repo, first, second) = two_commit_repo().await;
+
+    assert!(
+        git_is_ancestor(&repo, &first, &second)
+            .await
+            .expect("ancestor check forward"),
+        "first must be an ancestor of second"
+    );
+    assert!(
+        !git_is_ancestor(&repo, &second, &first)
+            .await
+            .expect("ancestor check reverse"),
+        "second must NOT be an ancestor of first"
+    );
+}
+
+/// Regression test for the deploy path that ate a committed agent config:
+/// `git_update_ref_cas` must refuse to move a ref whose current value is not
+/// the expected one, and must leave the ref untouched when it refuses. A bare
+/// `update-ref` accepts that move and silently drops everything in between.
+#[tokio::test]
+async fn update_ref_cas_refuses_stale_expectation() {
+    let (_dir, repo, first, second) = two_commit_repo().await;
+
+    // Park a ref at `first`, then CAS it forward with the correct old value.
+    git_update_ref(&repo, "refs/heads/cas", &first)
+        .await
+        .expect("plant ref");
+    git_update_ref_cas(&repo, "refs/heads/cas", &second, &first)
+        .await
+        .expect("CAS with the correct old value must succeed");
+    assert_eq!(
+        git_rev_parse(&repo, "refs/heads/cas").await.unwrap(),
+        second
+    );
+
+    // Now retry with the SAME (now stale) expectation, as a racing deploy
+    // holding a pre-merge sha would: it must fail rather than rewind.
+    assert!(
+        git_update_ref_cas(&repo, "refs/heads/cas", &first, &first)
+            .await
+            .is_err(),
+        "CAS accepted a stale old value"
+    );
+    assert_eq!(
+        git_rev_parse(&repo, "refs/heads/cas").await.unwrap(),
+        second,
+        "ref moved even though the CAS failed"
+    );
+}