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

Inizia dal punto di ingresso gh stack link e traccia la ricerca delle PR esistenti prima che venga chiamato createPullRequest. Riproduci il problema con branch uniti e chiusi, quindi confronta con gh pr list --head <branch> --state all. Il lavoro è completato quando le PR esistenti in qualsiasi stato vengono riconosciute e non viene tentata alcuna creazione duplicata.

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