[Unit PRs] Preserve delivered units across retry, cancellation and rewind #562

Part of #553. Suggested step 8 of 13; one focused PR into main.

Outcome: Recovery preserves external delivery history and resumes unresolved work without replaying or erasing units already merged into the base.

Depends on: #560, #561

Scope

• Use the shared delivery verifier before recovery mutation and reuse existing run/attempt/plan ownership checks atomically.
• Recover a merge that happened before its state write; retain receipts after source-branch deletion; preserve existing successful repository outcomes when others fail.
• Revisions to published work create an explicit new corrective attempt/PR. Cancellation and rewind cannot imply rollback, reopen a merged PR, or reset delivered history.
• For supported multi-repository runs, show partial delivery and block successors until resolved. For excluded configurations, retain admission rejection rather than quietly adding support here.

Acceptance criteria

• Crash-after-merge/before-write recovery records the delivery without creating a replacement PR.
• Cancelling after one unit merges preserves that result and leaves unresolved work identifiable.
• Retry/rewind skips intact delivered work; a requested change to it creates a distinct corrective identity.
• Partial delivery, deleted source branch, provider outage and stale recovery ownership cannot erase history or release dependents prematurely.
• Focused API/store/orchestration recovery tests cover races and legacy histories; normal recovery remains available for both existing strategies.

PR boundary and rollout

Recovery semantics for the agreed matrix only. No automatic revert, force-push to base, generic history migration or bundled provider expansion.

Related work to reconcile

Reconcile with #534 and the recovery/delivery contracts used by #537/#539 before implementation. They were open when this child was created; their branch code is not an assumed merged prerequisite. Build on the resulting main contracts or coordinate the overlap instead of adding a competing recovery model.

Starting points

lambda/intents/index.js, lambda/v2-orchestrator/section.js, lambda/shared/v2-process-store.js, lambda/shared/v2-process-keys.js.

Planning baseline: main at b5d68d5d2f12292d56a21aab917e4d8f9538aa0b (2026-10-15). Recheck current main and applicable guidance before implementation. Existing strategies remain supported; the new capability stays disabled until qualification.