[Bug] repair rounds are not wired to the findings they fix: false "failed without a follow-up repair", and auto-repair fires for reviews but not verifications

TL;DR

Two related defects in how repair rounds are wired:

1. A generated repair task depends on its own automatically-derived upstream, not on the failed task whose findings it fixes — so the causal link is invisible to the plugin. Delivery then reports failed without a follow-up repair for tasks whose findings were fixed and independently re-verified.
2. Auto-repair fires for a failed review but not for a failed verification. In the same run, a review failure produced a repair round automatically, while two verification failures produced none.

Environment

A · The causal link exists in the transcript but not in the graph

In every row the fix is complete. But the generated repair for row 1 depended on an earlier task (t7) rather than on the failed t13; the one for row 2 depended on the re-verification task rather than on the failed t15. Delivery therefore listed both as failed without a follow-up repair — a false alarm on an already-closed loop. We only untangled it by reading the task graph by hand.

B · Auto-repair is inconsistent across failure kinds

• A failed review produced a repair + follow-up review automatically, twice (t8 → repair → review, t18 → repair → review).
• A failed verification produced nothing; the status line read t9 failed without a follow-up repair, and the captain had to create the repair round by hand. The same happened for t13.

Since verification and review are both quality gates with the same contract (findings → repair → re-check), having only one of them self-heal is surprising, and the asymmetry is invisible until a captain hits it.

Impact

• The captain cannot trust Delivery: blocked. Its reasons mix real open work with closed loops whose edges were never drawn, and there is no way to tell them apart from the surface.
• When the loop does hit its limit (escalated), some of the listed causes may be artifacts of (A) rather than genuine unresolved findings — which makes "escalated" read as "there is still a defect" when in fact there may be none.
• Manual repair-round creation also reintroduces the ordering hazard: a hand-made repair can be dispatched while a verification of the previous revision is still running, which is exactly the collision described in #161.

Suggested direction

1. Make a repair task depend on the failed task whose findings it addresses (or on both that task and the auto-derived upstream), so the graph records the causality the transcript already has.
2. Trigger the same repair + re-check loop for a failed verification as for a failed review.
3. In Delivery, distinguish "work remains" from "work closed, edges missing" — and, when the loop is escalated, say which findings are genuinely unresolved versus which are already fixed downstream.

Trace repair-task generation, failed review and verification handling, and Delivery’s blocked or escalated reporting; compare the review path with the verification path and inspect how upstream dependencies are derived. Done means repairs link to the failed task whose findings they address, verification failures trigger the same repair and re-check loop, and Delivery distinguishes unresolved work from closed loops with missing edges.