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

Bắt đầu từ lệnh gh stack merge và hành vi của README được mô tả trong issue; tái hiện quy trình với một cặp được xếp chồng như các PR #104 và #111, sau đó kiểm tra các sự kiện merge, rebase, review và check. Hoàn thành khi lệnh xử lý an toàn base chưa được merge và nêu rõ mọi tác động phụ của force-push trước khi thay đổi một PR phụ thuộc đã được phê duyệt.

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.