Atomic stack merge is impossible when a ruleset dismisses approvals on merge-base change

[noranda]

Summary

In a repo whose ruleset stales approvals when a PR's merge base changes, an atomic stack merge can never succeed for stacks of ≥2 PRs: the merge itself changes the upper PRs' merge bases as it lands the lower ones, invalidating their (fresh) approvals mid-operation, and the all-or-nothing semantics then roll everything back.

Repro

1. Repo ruleset: require approvals + "approvals must postdate the last merge-base change" behavior (approvals are reported stale when the merge base moves), plus CODEOWNERS.
2. Stack of 2+ PRs, all layers freshly approved on their current heads, all checks green, nothing moving the base branch.
3. Run gh stack merge <stack> --yes --squash (or the UI Merge stack).

Result

✗ merge failed: Repository rule violations found
Waiting on 1 reapproval from someone other than the last pusher. N reviews are stale because they were submitted before the merge base changed.
Stack merges are atomic, so nothing was merged.

Verified the approvals were the last event before the merge attempt (submitted on the current head SHAs, after the last restack and after the base branch last moved) — so the only merge-base change that can be staleing them is the one performed internally by the atomic merge (layer N landing changes layer N+1's base).

Expected

The docs say rules for stacked PRs are "enforced against the stack's base branch for every pull request in the stack" — I'd expect the atomic merge's own internal retargets not to count as approval-invalidating merge-base changes (the approved diffs are unchanged). Otherwise atomic stack merges are unusable in any org with this rule, which is a common strict-review configuration.

Environment

gh 2.92.0, gh-stack (current as of 2026-09-01), GHEC org repo with rulesets + CODEOWNERS.