Extend action recovery reconciliation

docs/ACTION_EFFECT_AUTOMATION_LAYER.md

@@ -47,6 +47,9 @@ Recommended fields:
   irreversible
 - expected effects
 - idempotency key strategy
+- recovery mode: atomic, compensating, snapshot restore, forward recovery, or
+  irreversible
+- concrete verification steps which prove whether the effect occurred
 - audit event names
 - preview provider
 
@@ -89,10 +92,14 @@ The runner should execute an action plan as follows:
 4. Run permission and policy checks.
 5. Generate a consequence preview.
 6. Reserve or verify the idempotency key.
-7. Execute the owning module capability.
-8. Record observed effects.
-9. Emit events and audit records.
-10. Mark the command complete, retryable, quarantined, or requiring manual
+7. Create a durable recovery operation and acquire its execution fence.
+8. Persist dispatch evidence before a non-atomic provider call.
+9. Execute the owning module capability.
+10. Verify the provider result and every announced effect using the action's
+    declared recovery checks.
+11. Commit the local projection and verified recovery checkpoint together.
+12. Emit events and audit records.
+13. Mark the command complete, retryable, quarantined, or requiring manual
     intervention.
 
 The runner must never advance workflow state past a required side effect unless
@@ -110,7 +117,16 @@ between:
 6. reconciled, corrected, or compensated outcome.
 
 An API timeout after dispatch is not a failed effect and must not be retried as
-a fresh command. The actor context should retain the real identity/account,
+an ordinary process failure or a fresh command. The runner records an unknown
+outcome, releases its execution authority, and blocks continuation until an
+operator or provider reconciliation proves either that the effect occurred or
+that it is absent.
+
+`ActionDefinition.recovery_mode` and `recovery_verification` are part of the
+provider contract. The default is conservative forward recovery with explicit
+provider-result and effect verification. Atomic mode is valid only when the
+provider effect and its local projection share the same database transaction.
+The actor context should retain the real identity/account,
 represented function or party, delegation or power, and mandate/jurisdiction
 references when applicable. Domain modules remain responsible for deciding
 which of those references are required for their action.