link doesn't recognize a branch's existing merged/closed PR, tries to create a duplicate

## Summary

`gh stack link` looks up an existing PR for each branch argument, but the lookup appears scoped to **open** PRs only. For a branch whose PR already merged or was closed (unmerged), `link` reports no PR found and attempts to **create a new one** — contradicting the documented additive-only design ("existing PRs are never removed").

## Repro

1. Build a stack `main <- a <- b <- c <- d <- e` via `gh stack link`.
2. Merge `a` and `b`. Close `c` without merging (its content landed elsewhere, or it was abandoned).
3. Later, run `gh stack link` again with the full historical branch list (e.g. to fix `d`'s base after `c` closed):
`gh stack link a b c d e --base main`

## Actual

```
Checking existing stacks...
Pushing N branches to origin...
Looking up PRs for 5 branches...
Found PR #.. for branch d
Found PR #.. for branch e
Creating 3 PRs...
✗ failed to create PR for branch a: creating PR: GraphQL: was submitted too quickly, Head sha can't be blank, Base sha can't be blank, No commits between main and a, Head ref must be a branch (createPullRequest)
```

Only the still-open branches (`d`, `e`) were recognized as "Found PR". The merged branch `a` (whose content is already in `main`, hence "No commits between main and a") and the closed branch `c` were both treated as PR-less and queued for creation.

In my case the create call failed immediately on the first attempt (an already-merged branch has no diff vs. its base, so `createPullRequest` rejects it), so no duplicate PR was actually created — I confirmed this via `gh pr list --head --state all` for each affected branch afterward. But this looks like it depends on the specific branch/repo state; a branch that still has *some* diff against the base (e.g. a closed-but-unmerged PR whose branch wasn't cleaned up) would likely succeed in creating a genuine duplicate PR.

## Expected

`link`'s PR lookup should match a branch's PR regardless of state (open, closed, or merged) before deciding whether to create a new one, consistent with the "existing PRs are never removed" behavior documented for this command.

## Environment

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

Related: #372 (same investigation session, different symptom of the same overall stack-mutation scenario — see also the atomicity issue I'm filing separately).

Start at the `gh stack link` entry point and trace its existing-PR lookup before `createPullRequest` is called. Reproduce with merged and closed branches, then compare against `gh pr list --head --state all`. Done means existing PRs in any state are recognized and no duplicate creation is attempted.

Written by the indexing model from the issue text.