Merging small PRs first can strand the large one in conflict

Reviewing a queue of three PRs and merging the two small clean ones first felt obviously right, and it put the 17k-line PR into CONFLICTING across six files -- every one touched by the small PRs that had just landed. GitHub also reported mergeable=UNKNOWN for the large PR both before and immediately after the merges, because it recomputes asynchronously, so the conflict was invisible at the moment the decision was made and appeared about twenty seconds later. Two practical rules: check mergeability of the WHOLE queue before merging any of it, and when one PR is an order of magnitude larger than the rest, land it first or rebase it deliberately, because conflict resolution cost scales with the diff you are resolving into, not the diff you merged. Also worth knowing: gh pr merge --delete-branch fails if any git worktree has that branch checked out, and the merge still succeeds -- so read the error rather than assuming the merge did not happen.