bug(retained): destroy the environment when detached dispatch fails

[drewstone]

Reproduction

The retained start path creates an environment before detached dispatch.

If provider.create succeeds and environment.dispatch rejects, startRetainedRun propagates the dispatch error and does not call environment.destroy.

A focused injected-provider reproduction measured created=1, dispatched=1, destroyed=0 against @tangle-network/agent-runtime 0.132.6.

The missing cleanup is in the post-create path of startRetainedRun in src/runtime/retained-run-start.ts.

Impact

Each failed dispatch can leave one paid cloud environment alive until its external lifetime expires.

Braid hit the adjacent public path on 2026-08-12. Sandbox creation succeeded, dispatch returned HTTP 404, and only the external proof cleanup prevented a leak.

Required behavior

Wrap detached dispatch and exact-reference validation in cleanup.

Call environment.destroy when any post-create step fails before a RetainedRunHandle is returned.

Preserve the original error and include cleanup failure in an AggregateError.

Do not destroy an environment after a valid handle has crossed the admission boundary.

Completion proof

1. A dispatch rejection destroys exactly one created environment.
2. An invalid control reference destroys exactly one created environment.
3. A destroy failure preserves both errors.
4. A successful retained start does not destroy the environment.
5. The real Tangle Sandbox failure path leaves zero owned resources.

[drewstone]

The original cleanup requirement is unsafe for an idempotent create.

An independent Braid review reproduced this case: a retained create can return a pre-existing environment for the same idempotency key. If detached dispatch then fails, unconditional destroy deletes the existing workspace even though this attempt did not create it.

Braid now leaves an ambiguous environment to its bounded idle expiry. Runtime should compensate only after the provider returns a server-issued creation receipt that distinguishes new from replayed, or after an atomic admission operation proves ownership.

Please add two completion cases:

1. A newly created environment is destroyed after dispatch rejection.
2. A pre-existing environment returned by the same idempotency key survives dispatch rejection.

This narrows the original instruction to destroy after every post-create failure.