Various issues exhibited when local and remote base branch names are not the same

Due to having a single repo with many different forks of LLVM checked out into various worktrees, my local branch names for things like "main" are often prefixed; e.g. my local branch that tracks llvm/llvm-project is upstream-main. For most operations this seems to work fine, I could gh stack init --base upstream-main and create my stack locally. However, when it came time to submit, I got the following:

```
% gh stack submit --auto --open
Checking stack state...
? Multiple remotes found. Which remote should be used? upstream
? Save "upstream" as the default remote for all gh stack operations? No
Pushing to upstream...
⚠ failed to create PR for users/jrtc27/lld-test-aarch64-ifunc-bti: creating PR: GraphQL: Head sha can't be blank, Base sha can't be blank, No commits between upstream-main and users/jrtc27/lld-test-aarch64-ifunc-bti, Base ref must be a branch (createPullRequest)
✓ Created PR #210611 for users/jrtc27/lld-test-ppc32-ifunc-nonpreemptible
✓ Created PR #210612 for users/jrtc27/lld-replaceWithDefined-skip-copy
✓ Created PR #210613 for users/jrtc27/lld-handleNonPreemptibleIfunc-skip-pointless-alias
✓ Created PR #210614 for users/jrtc27/lld-handleNonPreemptibleIfunc-no-copy-constructor
✓ Created PR #210615 for users/jrtc27/lld-Symbol-remove-copy-constructor
✓ Created PR #210616 for users/jrtc27/lld-handleNonPreemptibleIfunc-addSyntheticLocal
✓ Stack created on GitHub with 6 PRs (stack #210617)
✓ Pushed and synced 7 branches
```

There are three issues here:

1. gh-stack should have been able to figure out that, given upstream-main is the base branch tracking refs/remotes/upstream/main, upstream is the sensible remote to automatically use (but that's a minor nice-to-have)
2. gh-stack should be querying the upstream branch for the base branch and using that as the branch name (minus the refs/remotes prefix), not the local branch (presumably only falling back to the local branch name if there is no upstream branch, if that's a sensible thing to do)
3. If creating a PR fails, gh-stack should stop before it makes things worse, as fixing this up manually is a bit of a pain (you have to create the missing PR, unstack the existing stack and only then can you re-stack the entire thing, since gh stack link currently doesn't let you add to the front of the stack, presumably due to the API being a bit deficient...)

从 gh stack submit --auto --open 流程开始，跟踪在创建 pull request 之前如何选择本地分支、upstream 跟踪 refs 和 remotes。重现报告的 upstream-main 情况，并验证发送到 GitHub 的基分支、remote 选择，以及创建 PR 失败后的行为。完成标准是解决报告中的全部三个问题，且不留下部分提交的 stack。

由索引模型根据 Issue 内容生成。