fix(ce-babysit-pr): restore managed-stack propagation after gh-stack atomic push fix

[tmchow]

Problem

ce-babysit-pr currently treats gh stack push as an atomic, all-or-nothing update of rewritten dependent branches.

The installed gh-stack v0.0.8 uses explicit per-branch --force-with-lease values, but its push command passes atomic=false even though its help and documentation promise --atomic. A rejected multi-branch push can therefore leave only part of the remote stack updated.

Upstream report: github/gh-stack#216

Interim behavior

Until an upstream release provides the documented atomic guarantee, babysitting should fail closed at the managed-stack mutation boundary:

• Continue watching and reporting review, CI, and branch state.
• Before any target-head push that would require upstack propagation, verify that the stack push path has the required atomic capability.
• If that capability is absent or cannot be proven, do not push the target or begin the dependent rebase. Surface a concise blocked-external / stack-sync residual that links the upstream dependency.
• Ordinary non-stack PR maintenance and manual dependency chains keep their existing behavior.

This avoids making the target move when the skill cannot safely propagate every dependent branch as one transaction.

Follow-up after the upstream fix

• Identify the first gh-stack release containing the fix for gh stack push advertises atomic updates but invokes git.Push with atomic disabled github/gh-stack#216.
• Add a version or capability gate that proves gh stack push supplies both explicit expected-OID leases and an atomic multi-ref update.
• Re-enable autonomous manager-owned upstack propagation only when that gate passes.
• Keep the active target excluded from the cascading rebase and force update.
• Abort and surface semantic rebase conflicts rather than resolving another PR layer's intent.
• After the push, verify every affected remote dependent matches its intended local OID before resuming the watch.
• Update SKILL.md, references/watch-loop.md, the public skill page, and contract tests so the documented failure semantics match the executable dependency.

Acceptance criteria

• Older, unknown, or affected gh-stack versions stop before the first target mutation that would require dependent propagation.
• A fixed and verified version can rebase dependents and push them with exact leases in one atomic transaction.
• A rejected transaction is treated as updating no remote dependent refs.
• Tests cover the capability gate, target exclusion, exact-lease requirement, atomic requirement, and blocked-external fallback.

[newbpydev]

Are you currently working on this issue?

If not, I would be happy to take it on. I am free this weekend and can start working on it.