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

从 gh stack merge 命令和 issue 中描述的 README 行为开始；使用类似 PR #104 和 #111 的堆叠对复现流程，然后检查 merge、rebase、review 和 check 事件。完成的标准是：命令能够安全处理尚未合并的 base，并在更改已批准的依赖 PR 之前明确说明任何 force-push 副作用。

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.