Eighteenth resolver from the coverage map on #3115, and **why** it was
uncovered is the interesting part.
## A fake that ignores its own filter cannot see a filter bug
Every case in this file stubs `listTasks` to return the same task
**whatever column is asked for**:
```ts
(store.listTasks as ...).mockResolvedValue([failedReviewTask()]);
```
So the project query is never exercised. Blinding `orphanReviewColumns`
changes which column is *requested*, the fake answers identically, and
nothing fails. Eight passing tests, and the selection logic among them
was untested.
That is the same blindness the production sweep had — querying a column
that does not exist and finding nothing — reproduced in the harness that
was supposed to catch it.
## The case
`listTasks` honours the column, so a card resting in a renamed review
lane is found **only if the query asked for that lane**. Keyed on the
id, the sweep asked for `in-review`, got nothing, and a failed
orphan-only card **stayed failed forever**.
## Measured
9 pass; blinding `orphanReviewColumns` fails exactly this case.
**18 of 26 pinned** across 17 merged PRs.
## Generalisation worth checking elsewhere
Any sweep whose test stubs `listTasks` with a flat `mockResolvedValue`
has this hole. The fix is a store fake that filters on `options.column`
— the shape `self-healing-query-filter-blindness.test.ts` already uses.
I would look there first for the remaining map entries.
## Verification
`self-healing-orphan-only-scope` **9 passed** · `pnpm test:gate` full
pass · lint — green.
73bff5f88c