Recover steering cancellation after transient delivery failures #718

Summary

An authenticated cancellation can remain pending after delivery fails, and resubmitting the same action does not retry the failed delivery.

Evidence and reproduction

On main fa0c79b9ae38eca2c59b2b1911becfe1a6b3c9ab, src/steering/plane.rs:527-550 appends a durable Pending submit event before delivery. The delivery error propagates at line 552. Reconstructing the journal preserves that event (src/steering/evidence.rs:94-103,215-230), and an identical resubmission returns the existing outcome at src/steering/plane.rs:529-536 without invoking delivery.

The cancellation branch can fail during child inspection or stop (src/steering/plane.rs:655-673). Sweep at lines 310-345 only marks timeout/lost-child outcomes and does not recover delivery.

A deterministic regression can inject one stop/inspection failure after submit persistence, reopen the plane, and resubmit the identical request before its deadline. Current control flow returns Accepted(Pending) without a second delivery attempt. The child may continue until another termination path acts or the request deadline expires.

Acceptance criteria

• An incomplete identical request safely resumes delivery, or records an explicit durable delivery-failure outcome with a controlled retry path.
• Recovery survives journal reconstruction and process restart.
• Keep cancellation idempotent for the exact run, assignment, action and process identity, including a failure after the child already exited.
• Preserve refusal when the same action ID is reused with different content.
• Add deterministic tests for pre-delivery failure, uncertain completion, retry before deadline, and restart.

Scope and verification

Source-level control-flow proof; no running process was stopped and no new test was executed for this report. Closed #335 delivered steering; the current defect is its incomplete-delivery recovery. No existing open Issue or open PR covers this path.