How can an environment test safe recovery from an uncertain posting response?

A simulated posting tool can accept `request_id`, `idempotency_key` and `expected_record_version`. Its response contract can distinguish rejected requests from responses lost after a successful commit. This creates a recoverable uncertainty that cannot be resolved from the timeout message alone.

Expose a `get_posting_status` action that searches by the original idempotency key. An agent can use that action before deciding whether another submission is needed. Reusing the same key for the same operation can return the existing result; using it with changed content can produce a defined conflict.

Evaluation hooks can inspect committed adjustment identifiers, submitted keys and the agent's recovery sequence. The success condition includes a single intended business effect and a correctly resolved case status, rather than merely a final successful tool response.

Reset must restore both ledger state and the idempotency registry. Otherwise, a later run may inherit a prior posting result. A buyer can ask for failure injection controls that reproduce the lost-response condition so different models face the same recovery problem.