[FLO-13.4c] Prove authority, duplicate-effect prevention, and recovery residuals

[szmyty]

Implementation ready for review in PR #69. Keep #66 and #31 open until maintainer merge; the PR closes both.

Parent: #31
Suite roadmap: #11
Depends on: #64 and #65

Outcome

Finish #31 by proving authority precedes effects, completed work is not silently duplicated, and interrupted/failed cleanup leaves honest inspectable residual evidence.

Acceptance criteria

• Use harmless sentinels/counters to prove denial before mutation, upload, publication, signing, network, paid-service, or other consequential effects; perform no real external actions.
• Prove successful work remains reusable without repeat launch, blocked descendants cannot run, and repeated/uncertain attempts require explicit matching recovery authority.
• Cover cancellation/failure while handling residual outputs or cleanup; preserve original and candidate evidence and identify uncertainty rather than claiming complete cleanup.
• Keep explanations typed, deterministic, actionable, and free of secrets, absolute roots, raw provider streams, and private content.
• Document the boundary between duplicate prevention for accepted work and uncertain external effects; do not claim exactly-once behavior for unconfined providers.
• Run focused local gates, link immutable scenario and validation evidence, and reconcile every original [FLO-13.4] Prove interruption, retry, resume, and authority state transitions #31 acceptance criterion in [FLO-13.4] Prove interruption, retry, resume, and authority state transitions #31/Build cross-tool orchestration and failure fixture suites #13/[EPIC] Finish the flow suite and prove production-ready orchestration #11. Record unverified hosted checks without waiting, per the maintainer's 2026-09-26 handoff instruction.

Boundaries

Use the existing durable models and checkpoint 1 assessment API. No real publishing, signing, upload, payment, provider-local checkpoint algorithms, or general automatic recovery scheduler. Any additional production seam must be bounded and documented before implementation.

Implementation and validation — 2026-09-26

Fifteen counter-backed recipes extend the corpus to 49: seven authority-denial categories, completed reuse, stale authority, explicit failed/interrupted recovery, recovery-decision replay, abandonment, and cancelled/failed partial cleanup. Runtime APIs and schemas are unchanged.

Evidence: immutable lifecycle guide, 49-recipe catalog, and local validation record.

Rust 1.85 passed all targets, including all 81 acceptance recipes and 49 lifecycle recipes twice each. Stable Rust passed the 49 lifecycle recipes twice. Focused Clippy, formatting, documentation tests, contract/repository validators, and negative report checks passed. Hosted CI and macOS/Windows results were not checked or awaited, per the maintainer's 2026-09-26 instruction.

The counter proves no silent relaunch of accepted work. Explicitly acknowledged uncertain retries can repeat an effect; the fixture demonstrates that boundary. Upload uses network permission, paid-service use uses AI-provider permission, and cleanup is synthetic provider behavior. No real external actions, automatic cleanup, sandbox enforcement, or exactly-once claim is introduced.