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

Comienza con el comando gh stack merge y el comportamiento de README descrito en el issue; reproduce el flujo con un par apilado como los PRs #104 y #111, y luego inspecciona los eventos de merge, rebase, review y check. Se considera terminado cuando el comando maneja de forma segura la base no fusionada y hace explícito cualquier efecto secundario de force-push antes de cambiar un PR dependiente aprobado.

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.