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

从 gh stack submit 流程开始，使用针对 stack 和一个开放 PR 的未缓存 gh api 检查来重现报告的状态。跟踪 stack 的重新创建过程，包括远程持久化和本地 .git/gh-stack 更新。完成的标准是失败时返回非零值，而只有在验证替换后的 stack 以及预期的 PR 成员关系之后才打印成功信息。

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

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:

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

Result:

null

Listing repository stacks showed only the old closed stacks:

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:

✓ 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.