gh stack merge retries against an unmerged base PR, then silently rebases and dismisses approvals on the dependent PR

Beginne mit dem Befehl gh stack merge und dem im Issue beschriebenen README-Verhalten; reproduziere den Ablauf mit einem gestapelten Paar wie PRs #104 und #111 und untersuche anschließend die Merge-, Rebase-, Review- und Check-Ereignisse. Als abgeschlossen gilt, wenn der Befehl sicher mit der nicht gemergten Basis umgeht und jeden Force-Push-Nebeneffekt explizit macht, bevor ein genehmigtes abhängiges PR geändert wird.

Phase 1 — 3 failed attempts before anything merged (15:26–15:31 UTC):
Triggered "Squash and merge stack" from the PR #111 web panel three times. Each attempt logged a real auto_merge_disabled event on PR #111 only (15:26:58, 15:27:55, 15:30:34) — none on PR #104, the actual bottom-of-stack PR that must merge first. Per the README, gh stack merge is meant to be "all-or-nothing," but it appears to arm merge/auto-merge on the dependent PR before confirming the base PR has landed, hits an unresolved mergeable state, and aborts instead of waiting or retrying automatically — surfacing as a confusing "not mergeable" error with no indication that nothing had actually merged.

Phase 2 — merge manually, but silently strips approvals (15:35:23–15:35:29 UTC):
PR #104 squash-merged successfully. Immediately after:

• PR #111 was rebased — all 3 commits got new SHAs with identical timestamps (a full rewrite, not just a base pointer change), then force-pushed.
• All 3 existing approving reviews were dismissed (confirmed via review_dismissed events), reverting reviewDecision to REVIEW_REQUIRED.
• Every CI check reset to pending.

Our org's ruleset has dismiss_stale_reviews_on_push: false — this dismissal happened regardless, because it was a history-rewriting force-push rather than an append-only push (which GitHub dismisses reviews for unconditionally). That's expected GitHub behavior for that specific push, but the push itself was an undisclosed side effect of the merge action — the PR content is byte-identical to what was approved, yet 3 reviewers now have to re-approve and CI has to fully rerun, with zero warning in the UI before this happened.

Ask: gh stack merge should either (a) confirm the base PR is actually merged before touching the dependent PR, and (b) warn — or offer a non-rebasing retarget path — before force-pushing an already-approved PR as a side effect of merging the layer beneath it.