Why does `gh stack rebase --upstack` include the current branch?

Say I have the following stack

```
main <- branch1 <- branch2 <- branch3
```

I'm _on_ `branch1`, and just addressed some reviewer feedback by adding a few extra commits. Now I need to do the following:

- rebase `branch2` on `branch1`
- rebase `branch3` on `branch2`

I do _not_ want to rebase `branch1` on `main` right now.

My instinct is to call `gh stack rebase --upstack` while on `branch1`, where I just addressed the feedback and added commits. I was expecting that to do what I outlined above and not change `branch1` in any way.

Surprisingly (to me), it did this:
- rebase `branch1` on `main`
- rebase `branch2` on `branch1`
- rebase `branch3` on `branch2`

Can I ask about why `--upstack` includes a rebase of the current branch on the branch under it? That actually feels a bit "down stack"-ish to me.

It feels like this exact workflow is going to be pretty common for me, and the current workaround is for me to `gh stack switch` up to `branch2` and _then_ run `gh rebase --upstack`, but that feels pretty unnatural to me!

The entry point is `gh stack rebase --upstack`; first reproduce it on the stack described in the issue and inspect how the command selects branches. Compare the observed sequence with the requested sequence, then check the command's existing tests if available. Done means rebasing from `branch1` leaves it unchanged while rebasing `branch2` and `branch3` onto their updated predecessors.

Written by the indexing model from the issue text.