Design: separate a stacked PR's merge target from its base

From [Overview / What Is a Stack?](https://github.github.com/gh-stack/introduction/overview/#what-is-a-stack):

> A pull request stack consists of two or more pull requests in the same repository where:
>
> - The first (bottom) pull request targets the main branch (e.g., main).
> - Each subsequent pull request targets the branch of the PR below it.
```
┌── feat/frontend → PR #3 (base: feat/api-endpoints) ← top
┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)
┌── feat/auth-layer → PR #1 (base: main) ← bottom
main (trunk)
```

[endquote]

_Merging to the base branch is fundamentally wrong for this._ In your example here, `api-endpoints` is not logically *part of* `auth-layer`, so should not merge to it. You should separate "base" and "target" (e.g. `main`, `super-feature`, etc). Normally all branches in a stack will merge to the same target.

You already track "target" as distinct from base - your own [Overview](https://github.github.com/gh-stack/introduction/overview/#what-is-a-stack) states each PR is evaluated for rules and protections using "its final target branch (e.g., `main`), not the branch it directly targets." So the concept exists; it's just confined to rule evaluation and discarded everywhere else. Promote it to a first-class merge destination.

Result should be something like:

```
$ git log --all --graph --decorate --pretty=oneline --abbrev-commit
* 043bf03 (HEAD -> main) Merge pull request #2 from username/feat/2
|\
| * 88624f8 (feat/2) Feature 2
* | 39f3460 Merge pull request #1 from username/feat/1
|\|
| * 0f1e961 (feat/1) Feature 1
|/
* 04a9dac Initial commit
```

Related, I made the [same point to Git Butler](https://github.com/gitbutlerapp/gitbutler/issues/10936), but they're constrained by the existing GitHub implementation. But you are GitHub, now deciding the next implementation - not constrained.

Along with this, the implementation should display and enforce "below" branches in the stack as prerequisites. `feat/2` should be blocked from merging until `feat/1` has merged. You'll have to make this explicit, instead of just a side effect of merging to the base branches.

Comece pela descrição vinculada Overview / What Is a Stack? e trace como o gh-stack atualmente representa os destinos finais, as branches base e o comportamento de merge. Defina o destino de merge separado e o comportamento explícito de pré-requisito para branches empilhadas e, em seguida, verifique se o histórico resultante corresponde ao exemplo e se as branches superiores não podem sofrer merge antes das inferiores.

Escrita pelo modelo de indexação a partir do texto da issue.