Inserting a layer in the middle of a stack requires unstack + link, which permanently drops merged PRs

### Summary

There is no way to insert a layer in the middle of an already-submitted stack while keeping the stack's merged PRs as members. The only working procedure (`unstack` + `link`) moves the still-open PRs into a **new** stack and leaves every merged PR behind in the old one, which is then closed. The historical grouping of the stack is lost, permanently and irreversibly.

### Current behavior

Given a submitted stack `S` with, bottom to top, one merged PR `#1` and open PRs `#2 → #3 → #4`, and the need to insert a new layer between `#2` and `#3`:

1. `gh stack modify` is TUI-only, so it is unusable non-interactively (and it restructures the local stack, not the server-side membership of an existing PR).
2. Retargeting the base of an existing stacked PR is refused:
- REST `PATCH /repos/{o}/{r}/pulls/{n}` → `HTTP 422 … PullRequest.base is invalid`
- `gh pr edit --base ` → `Cannot change the base branch because the pull request is part of a stack`
3. `gh stack link` only appends to the top (`gh stack link `); it has no position/insert argument, and it rejects arguments that belong to a different stack.
4. So the only way out is `gh stack unstack ` + `gh stack link … `. `unstack` (v0.1.0) unstacks the open PRs and leaves the merged `#1` in `S`; `S` becomes `open: false` with `#1` as its sole member, and `#1` cannot be linked into the new stack (rejected as belonging to another stack).

Net effect: a purely structural edit in the middle of the stack silently destroys the association between the merged layers and the layers that are still in flight.

### Expected behavior

Either of:

- **Insertion**: a way to place a PR/branch at an arbitrary position of an existing stack, e.g. `gh stack link --after ` / `--before ` / `--position `, without tearing the stack down.
- **Lossless rebuild**: allow merged PRs to be re-linked into a stack (or have `unstack` + `link` carry them over), so the recovery procedure above at least preserves the full history of the stack.

### Why it matters

Merged layers are exactly the part of a stack that documents *why* the remaining layers look the way they do. Keeping them attached is useful today when reading the stack, and it is what would let the web UI group a whole line of work — landed and in flight — under a single stack. Today, any mid-stack restructuring resets that grouping, so long-lived stacks progressively lose their own history.

### Environment

- `gh stack version 0.1.0`
- Private repository, stacks enabled.

Start by reproducing the reported gh stack link and gh stack unstack behavior, then inspect the REST PATCH /repos/{o}/{r}/pulls/{n} limitation and the existing stack membership flow. Done means a mid-stack insertion or lossless rebuild preserves merged PR membership and keeps the full stack history intact.

Escrito por el modelo de indexación a partir del texto del issue.