gh stack submit falsely reports stack recreation when no replacement stack is persisted

### Summary

`gh stack submit` reports that a modified stack was successfully recreated on GitHub, but no replacement stack exists afterward.

Branches and PR bases are pushed successfully. Open PRs become unstacked, local metadata retains the old closed stack ID, and the command still exits with success output.

### Environment

- `gh version 2.97.0`
- `gh stack version 0.1.0`
- macOS 26.6
- Repository has GitHub Stacks enabled

### Setup

Existing remote stack:

- One merged bottom PR
- Multiple open PRs
- One closed PR in the middle

Locally:

1. Check out remote stack.
2. Run `gh stack modify`.
3. Drop the closed middle PR.
4. Resolve cascading rebase conflicts.
5. Run `gh stack submit`.

### Actual output

```text
Found the stack on GitHub — updating it to match your local stack
Merged PRs have left the stack on GitHub, so it wasn't updated — your unmerged PRs were pushed and re-based onto the trunk
✓ Stack recreated on GitHub to match local state
✓ Pushed and synced 47 branches
```

### Actual remote state

The branches were pushed, but no replacement stack was created.

Repeated uncached API checks showed:

```bash
gh api -H 'Cache-Control: no-cache' \
repos/OWNER/REPO/pulls/OPEN_PR \
--jq '.stack'
```

Result:

```json
null
```

Listing repository stacks showed only the old closed stacks:

```bash
gh api -H 'Cache-Control: no-cache' \
'repos/OWNER/REPO/stacks?per_page=100'
```

The old stack remained closed with only its merged PR. No new stack number appeared.

This was checked three times over 12 seconds. Direct PR membership and the stack list remained unchanged.

Local `.git/gh-stack` still referenced the old closed stack number and ID.

### Expected behavior

One of:

1. A replacement remote stack is persisted and local metadata is updated to its new number and ID.
2. Stack creation failure is reported with a non-zero exit code.

The command must not print:

```text
✓ Stack recreated on GitHub to match local state
```

unless the remote stack exists and its PR membership has been verified.

### Impact

- User believes stack recreation succeeded.
- GitHub UI contains no open stack.
- Every open PR has `stack: null`.
- Local metadata points to a closed historical stack.
- Subsequent `checkout`, `sync`, and `modify` operations begin from inconsistent state.

### Suggested safeguard

After creating or recreating the stack:

1. Read the returned stack ID and number.
2. Query the stack or one member PR.
3. Verify expected membership.
4. Only then persist local metadata and print success.

If verification fails, retain recovery state and return an error.

Start with the `gh stack submit` flow and reproduce the reported state using the uncached `gh api` checks for the stack and an open PR. Trace stack recreation through remote persistence and local `.git/gh-stack` updates. Done means failures return non-zero, while success is printed only after the replacement stack and expected PR membership are verified.

Written by the indexing model from the issue text.