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

Beginne beim Einstiegspunkt gh stack link und verfolge die bestehende PR-Suche, bevor createPullRequest aufgerufen wird. Stelle das Verhalten mit gemergten und geschlossenen Branches nach und vergleiche es anschließend mit gh pr list --head <branch> --state all. Als erledigt gilt die Aufgabe, wenn bestehende PRs in jedem Status erkannt werden und keine doppelte Erstellung versucht wird.

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 <branch> --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).