Allow changing the base branch of an existing stack

[yorkyang2333]

Problem

There is currently no straightforward way to change the base branch of an existing stacked PR stack.

For example, suppose an existing stack is:

main
└── PR #1
    └── PR #2
        └── PR #3

I may later need to move the entire stack to another target branch:

release/1.x
└── PR #1
    └── PR #2
        └── PR #3

This is different from retargeting an individual PR. The intention is to migrate the whole stack to a new trunk while preserving the existing stack structure.

Current behavior

The base branch of a stacked PR cannot be changed directly. In particular, the first PR in the stack cannot have its base branch changed from the GitHub web UI, even though this PR is the entry point of the stack and changing its base would naturally correspond to changing the stack's trunk. The same limitation exists from the CLI/API side: attempting to change the base of a PR that is part of a stack is rejected.

The current workaround is to unstack the entire stack, change the base of the bottom PR, and then recreate/relink the stack. For a larger stack, this is unnecessarily cumbersome and makes a simple change to the stack's destination require rebuilding the stack.

Expected behavior

There should be a way to change the trunk of an existing stack without unstacking and recreating it.

Web UI

For the first PR in a stack, the normal Change base UI should allow selecting another base branch. Changing the base of the first PR should update the stack's trunk while preserving the rest of the stack:

Before:

main
 ↓
PR #1
 ↓
PR #2
 ↓
PR #3

After changing PR #1's base:

release/1.x
 ↓
PR #1
 ↓
PR #2
 ↓
PR #3

The remaining PRs should continue to point to the PR immediately below them.

CLI

Provide an explicit way to retarget an existing stack, for example:

gh stack retarget --base release/1.x

or:

gh stack modify --base release/1.x

The command should:

1. Change the trunk of the existing stack.
2. Retarget the bottom PR to the new trunk.
3. Preserve the existing ordering and relationships of all other PRs.
4. Ideally rebase/sync the stack onto the new trunk as part of the operation, or provide a clear follow-up command.

Why this matters

Changing the target branch of a feature is a normal workflow, especially when development moves between main, release branches, maintenance branches, or other integration branches. A stacked PR should be treated as a single unit for this operation: changing its destination should not require destroying and recreating the stack metadata just to update its trunk.

At minimum, the first PR in a stack should be allowed to use the standard Change base functionality in the GitHub web UI, since that PR defines the stack's trunk.