backlog-burndown: the ranking can re-dispatch an issue this run already fixed

[ptr727]

backlog-burndown "The Round" step 1 ranks "every open issue", and step 8 re-ranks from scratch. Nothing in "Ranking" excludes an issue this same run has already fixed, and such an issue is still open by this skill's own design.

The mechanism, end to end:

1. A worker fixes an issue and its feature pull request squash-merges to develop. The closing keyword is deliberately not on that pull request, because a develop-targeted Fixes #N is inert, so the issue stays open. Closes on promotion: puts the closure on the promotion pull request instead, which merges to main.
2. Step 6 then cleans up: the worktree, the local branch, and the merged remote branch all go, and the claim comment goes with them.
3. Step 8 prepares the next round under the freeze, which is where the ranking is computed, and "The Promotion Boundary" step 7 says "The merge unfreezes the run, and the prepared round dispatches then". So the ranking is computed while those issues are still open, and dispatch happens after the merge that closes them.
4. Step 3's claim verification cannot catch it. The worktree is gone, both branches are gone, and the merged feature pull request is no longer open, so none of the three branch reads and no claim comment reports anything.

The result is a worker dispatched to fix an issue this run already fixed, against a develop that already carries the fix. The fix belongs in "Ranking" as an exclusion on the ranking inputs, since that is the one place with the information: an issue whose fix is already on develop is not a candidate, however open it is.

This is not the same as #1279, which is about an unanswered question-issue being re-prompted every round, nor #1277, which covers step 8 preparing under the freeze in general. This one is specifically that the ranking has no notion of "already fixed but not yet promoted", which is a state this skill creates on purpose.

Two smaller items in "Ranking" from the same read:

• "Where a repository does carry one, that label is the first input and these criteria order what it leaves tied" gives no ordering for a partially-labeled backlog. A labeled and an unlabeled issue are not tied on the label, and nothing says whether an unlabeled issue sorts above, below, or among the labeled ones. Distinct from the conjunction defect in backlog-burndown: an unanswered question issue is re-sent every round, and the priority-label conjunction leaves a case uncovered #1279.
• "The Round" step 1 says "Rank every open issue", and "Ranking" says a question-issue "is not ranked". The per "Ranking" delegation only partly rescues it, since the reader is told to rank every issue and then told a class of them is not ranked.

Raised by the local-strict-review carried-content passes on the pull request that added this skill, and deferred there under that skill's own review-round budget.