Support idempotent sandbox creation with a client-supplied request identity

Is your feature request related to a problem? Please describe.

Durable orchestrators cannot safely recover an ambiguous sandbox-creation result through the current Python SDK/API contract. AsyncSandbox.create() accepts metadata, but no client-supplied idempotency identity. If the provider accepts POST /sandboxes and the client process dies or loses the response, a retry can create a second sandbox. Avoiding the retry can instead strand work when the original request never committed.

Listing by metadata does not close this gap: metadata is not a uniqueness constraint, and an empty observation cannot prove that an in-flight create will not become visible later.

Describe the solution you'd like

Support a client-supplied idempotency key for sandbox creation in the API and Python SDK, with a documented contract such as:

• concurrent or later retries with the same key and equivalent create parameters return the exact same sandbox identity;
• reuse of the key with different create parameters returns a typed conflict;
• acknowledgement loss and request timeouts do not permit duplicate allocations;
• the retention period and terminal retry behavior are documented;
• the idempotency key is treated as request identity rather than guest-visible metadata.

This would let a caller durably persist an allocation intent before dispatch and then safely replay creation after process loss.

Describe alternatives you've considered

• Querying by unique-looking metadata and adopting one result is observational, not atomic, and can miss a late allocation.
• Creating again and deleting duplicates still has an unbounded late-arrival window.
• Never retrying fails closed but leaves an allocation intent permanently unresolved when the first request did not commit.

Additional context

This requirement was found while implementing crash-recoverable remote environment allocation in Cayu: https://github.com/vertexkg/cayu/issues/540

The audited SDK version is e2b==2.28.0.

Start by tracing Python SDK AsyncSandbox.create() to the POST /sandboxes API contract in the audited e2b==2.28.0 version. Review how request identity and sandbox creation errors are represented, then define the conflict, retry, retention, and terminal-response behavior. Done means equivalent retries reuse one sandbox, differing parameters produce a typed conflict, and the contract is documented.