A failed link call leaves the target stack's membership partially mutated

## Summary

When `gh stack link` fails partway through (see #373 for one way to trigger this), the stack's membership on GitHub is left altered rather than restored — PRs that were part of the stack before the failed call are silently dropped from it, with no rollback and no mention of this in the command's error output.

## Repro

1. Build a stack `main <- a <- b <- c <- d <- e` via `gh stack link`. Confirm via `gh api repos/{owner}/{repo}/stacks/{id}` that all 5 PRs are listed under `pull_requests`.
2. Merge `a` and `b`. Close `c` without merging.
3. Run `gh stack link a b c d e --base main` to fix `d`'s base (see #373) — it fails while trying to create a duplicate PR for `a`.
4. Re-check the stack's membership: `gh api repos/{owner}/{repo}/stacks/{id} --jq '.pull_requests[].number'`.

## Actual

Before step 3, the stack listed all 5 PRs. After the failed `link` call in step 3, the stack's `pull_requests` field lists **only** the merged PRs (`a`, `b`) — `c`, `d`, and `e` are gone from the stack entirely, even though `d` and `e` were never touched by the failed create attempt (only the lookup step "found" them, per #373's output).

This is also visible in the GitHub UI: PRs that previously showed a "Part of a stack" banner no longer show it at all.

I did not attempt to trigger this deliberately — it was an unwanted side effect discovered while working around #373 and #372.

## Expected

Either:
- The whole `link` operation should be atomic: a failure partway through (e.g. an individual PR-creation error) should not leave the stack's membership altered from before the call, or
- If partial application is intentional/unavoidable, the command should clearly report which stack-membership changes actually took effect before it errored out, so the caller can reconcile the difference instead of discovering it later via the API or UI.

## Environment

`gh-stack` version 0.0.8, installed via `gh extension install github/gh-stack`.

從 gh stack link 命令開始，按照此 issue 中的步驟重現失敗，然後檢查影響 repos/{owner}/{repo}/stacks/{id} 成員關係的呼叫。追蹤 PR 建立嘗試失敗時如何處理先前和後續的成員關係變更。完成標準是：失敗的連結要麼保留原始的 pull_requests 成員關係，要麼明確回報每一項部分變更，並透過 API 進行驗證。

由索引模型根據 Issue 內容生成。