HTTP 422 when resubmitting a stack with a new bottom branch after merge

## Summary

When using `gh stack`, submitting a stack fails if the **bottom branch in the stack has been merged** and a **new branch is subsequently added below the remaining stack**.

`gh stack submit` detects that the local stack has changed and offers to overwrite the existing stack on GitHub, but the overwrite fails because the existing GitHub stack still contains the previously merged branch.

## Reproduction

Start with a stack containing three branches:

```text
main
│
▼
branch-a
│
▼
branch-b
│
▼
branch-c
```

Submit the stack with `gh stack submit`.

At this point, the GitHub stack looks like:

```text
main
│
▼
branch-a
│
▼
branch-b
│
▼
branch-c
```

### 1. Merge the bottom branch

Merge the PR for `branch-a` into `main`.

The remaining stack is now effectively:

```text
main
│
▼
branch-b
│
▼
branch-c
```

### 2. Add a new branch below the stack

Create `branch-d` from `main` and add it to the bottom of the local stack.

The local stack is now:

```text
main
│
▼
branch-d
│
▼
branch-b
│
▼
branch-c
```

So the local stack has changed from:

```text
main
│
▼
branch-a
│
▼
branch-b
│
▼
branch-c
```

to:

```text
main
│
▼
branch-d
│
▼
branch-b
│
▼
branch-c
```

### 3. Submit the modified stack

Run:

```bash
gh stack submit
```

`gh stack` detects that the local stack has been modified and asks:

```text
✗ a modify was completed but the stack has not been submitted yet

? The local stack has been modified. Overwrite the existing stack on GitHub? Yes
```

The submit then fails with:

```text
⚠ Failed to delete existing stack: HTTP 422: Pull request #650 cannot be removed from this stack
(https://api.example.ghe.com/repos/org-name/repo-name/stacks/656/unstack)
```

## Expected behavior

`gh stack submit` should reconcile the local stack with the existing GitHub stack.

The following workflow should be supported:

```text
Create stack
↓
Submit stack
↓
Merge bottom branch
↓
Add a new branch below the remaining stack
↓
Submit stack again
```

After submitting, the GitHub stack should reflect:

```text
main
│
▼
branch-d
│
▼
branch-b
│
▼
branch-c
```

The previously merged `branch-a` should no longer be part of the stack.

## Actual behavior

The submit operation attempts to overwrite the existing GitHub stack, but fails while trying to remove the existing stack:

```text
HTTP 422: Pull request #650 cannot be removed from this stack
```

This prevents the modified local stack from being submitted.

## Possible cause

It appears that merging the bottom branch leaves the existing GitHub stack in a state that cannot subsequently be replaced when a new branch is inserted below the remaining stack.

The problematic sequence appears to be:

```text
Initial GitHub stack:

main
│
▼
branch-a
│
▼
branch-b
│
▼
branch-c

│
│ merge branch-a
▼

Local/GitHub stack:

main
│
▼
branch-b
│
▼
branch-c

│
│ add branch-d below branch-b
▼

Local stack:

main
│
▼
branch-d
│
▼
branch-b
│
▼
branch-c

│
│ gh stack submit
▼

HTTP 422 while removing the existing stack
```

The error references the top branch (`branch-c` / its PR), even though the structural change is at the bottom of the stack.

This may indicate that the stack replacement/unstack operation is trying to remove or reorder PRs in an order that is invalid after the original bottom PR has already been merged.

## Environment

* `gh stack`: `0.1.0`
* OS: `macOS`

## Minimal reproduction

```text
Initial:

main
└── branch-a
└── branch-b
└── branch-c

Merge branch-a:

main
└── branch-b
└── branch-c

Add branch-d below branch-b:

main
└── branch-d
└── branch-b
└── branch-c

gh stack submit
→ HTTP 422
```

The expected result is that the final stack is successfully updated to:

```text
main
└── branch-d
└── branch-b
└── branch-c
```

Start at the `gh stack submit` overwrite flow and the stack replacement request to `/repos/org-name/repo-name/stacks/656/unstack`; reproduce the sequence of merging `branch-a`, adding `branch-d`, and resubmitting. Done means the existing stack can be replaced without HTTP 422 and GitHub reflects `branch-d`, `branch-b`, and `branch-c`.

Written by the indexing model from the issue text.