Which hooks reveal duplicate posting after a tool timeout?

Add a failure-injection hook immediately after a posting transaction commits but before its response reaches the agent. The agent sees a timeout even though the ledger has changed. This creates a different problem from a rejected transaction: the outcome is unknown to the caller.

A posting contract can require an `idempotency_key` tied to the intended operation. Repeating the same request with that key should return the original result rather than create another adjustment. Reusing the key with changed payload content should produce an explicit conflict.

Capture `operation_id`, `request_digest`, `commit_id` and `response_delivered` in evaluator traces. Provide an agent-facing `get_operation_status` action without exposing the failure injector. The evaluator can then determine whether the agent recovered the committed result or introduced a second financial change.

Reset must restore the ledger and the idempotency registry together. Otherwise, replaying a task may return a commit from a previous run. Inspect both final balances and committed operation counts to detect recovery failures that a later compensating entry could conceal.