gh pr merge --squash --delete-branch: dependent PR closed instead of auto-retargeted to merged PR's base

### What happened

A stacked-PR setup: PR #8 (`feat/fix` → base `feat/base`), where `feat/base`
was the head of open PR #7 (`feat/base` → `main`). The stack was assembled
with `gh stack init --adopt` — PR #7 predated the stack and was adopted as
the trunk when the descendant PR was created via `gh stack submit`. Both were
otherwise ordinary PRs with an ordinary base relationship.

I then ran: `gh pr merge 7 --squash --delete-branch`

Per the docs, deleting a merged PR's head branch should retarget open PRs
based on it to the merged PR's base branch. Instead, PR #8 was **closed**.

Timeline evidence (`gh api repos/OWNER/REPO/issues/8/timeline`):

- 19:56:28Z — PR #7 merged (squash)
- 19:56:29Z — `base_ref_deleted` event on PR #8
- 19:56:30Z — `closed` event on PR #8 (no retarget attempted)

### Recovery was a dead end

- `gh pr edit 8 --base main` on the closed PR: "Cannot change the base branch
of a closed pull request."
- `gh pr reopen 8`: refused while the base branch was deleted (expected), but
**also** refused after restoring the base branch, because the head branch
had been rebased/pushed while the PR was closed. Catch-22: the PR had to be
abandoned and recreated as a new PR, losing its identity.

### Questions

1. Is auto-retarget on branch deletion only wired to the web UI's post-merge
"delete branch" flow, and not to a raw ref deletion via the REST API
(which is what `--delete-branch` performs)?
2. If so, should `gh pr merge --delete-branch` warn when open PRs are based
on the branch being deleted?

(If this is platform-side rather than CLI-side, happy to have it routed.)