What tool actions can a simulated routing environment expose?

A simulated environment could expose `read_request`, `list_destinations`, `propose_assignment` and `commit_assignment`. Each action should have a schema describing required arguments, permitted side effects and possible errors.

For CASE-0856, `read_request` could return `owner_queue_id`, `status` and `state_version`. The assignment action would submit `destination_id`, `expected_version` and an `idempotency_key`. If another actor changes the case after the read, the environment can reject the outdated assignment and require the agent to inspect the new state.

An append-only event table can record `event_id`, `request_id`, `actor_role`, `previous_owner`, `new_owner` and `result_code`. This supports evaluation of attempted actions as well as final ownership. Retrying the same successful operation should not create duplicate handovers under the defined tool contract.

MirrorFirm could generate the initial state, competing actor events and task objectives. A reset operation can restore a named snapshot and clear episode-specific mutations. Evaluation hooks can check whether the agent handled a version conflict correctly, rather than merely arriving at the expected queue after an unsafe sequence of writes.