Fourteenth resolver from the coverage map on #3115, and it is the other
half of a sweep **I converted and tested myself**.
The file already pinned `mergedReviewColumns`. Blinding
`mergedHoldColumns` back to `["todo"]` left all 71 tests green — no case
put a merge-confirmed card in a renamed hold lane.
## The lane is not hypothetical
A merge-confirmed card gets **rebounded to hold** by other recovery
paths — a failed post-merge step, a requeue. So *merged but sitting in
hold* is exactly the state this sweep's second bucket exists to
finalize. Keyed on the id, that bucket read nothing on a renamed board
and the card stayed unfinished **while its commit was already on the
base branch**.
## The lesson, repeated
This is #3138's finding again: a test that pins one resolver of a pair
reads as covering the sweep. I wrote the earlier case, recorded the
sweep as done, and it was half-done.
**Only blinding each resolver separately finds this.** A single passing
revert proves one guard — which is why the map is keyed by resolver, not
by sweep.
## Measured
72 pass; blinding `mergedHoldColumns` fails exactly this case.
**14 of 26 pinned** across 13 merged PRs.
## Verification
`self-healing-query-filter-blindness` **72 passed** · `pnpm test:gate`
full pass · lint — green.
39a2e0481a