Ask: tell apart Docker leftovers of different reviews sharing one daemon #65

Follow-up from PR #54 (Ask in the lane D container). Copilot's final review summary on validated head 6f047ac says "unresolved moderate issues remain in … shared Docker-resource isolation" but gives no finding or location. This issue records the known limit behind it, which is already documented in docs/implementation/agent-isolation.md.

Current behavior

Ask fails closed on leftovers it cannot identify:

• The first question of each process scans for containers, volumes and networks labelled io.codeboost.allocation, io.codeboost.invocation or io.codeboost.egress.
• While an unidentified-leftover marker is recorded, any such resource keeps Ask off.

Lane D's labels carry an allocation, invocation or egress ID but no runner identity. So a second codeboost process working on a different review against the same Docker daemon can make this review's Ask refuse to start. The per-review OS lock (<database>.ask-leftovers.json.lock, keyed by file identity) prevents overlap only within one review database.

This is a false refusal (fail closed), not a leak: nothing belonging to another review is deleted.

Depends on

#51 item 3: runnerOwner plus attempt and allocation labels on every lane D resource. Item 4 (recoverLeftovers(runnerOwner) with authenticated recovery handles) would also let Ask remove its own leftovers instead of only detecting them.

To close this issue

• Once D follow-ups required by the F1 runner lifecycle contract #51 items 3 and 4 land, scope Ask's startup and unidentified-leftover scans to this runner's runnerOwner label, and reclaim through D's recovery API.
• Remove the stopgaps in runner/question-leftovers.ts that only exist because resources lack an owner.
• Add a test with two runners on one daemon. Each must see only its own leftovers, and one runner's live resources must not block the other's Ask.