Create a Dojo sim session and begin the runner ("Begin Sim").

Creates a dojo_sim_sessions row for the agent + scenario and starts the server-side runner (a per-session Durable Object that drives the Agent Smith ↔ agent loop and survives the human closing the tab). The runner resolves the agent's gateway compute key server-side BY agent_id (via the agent↔TryMeConfig link from onboarding) — the cleartext key never travels in the request. Emits SimEvents readable via GET /v1/sim/{session_id}/stream. MNE-531.

This operation returns 409 for THREE distinct causes; branch on the stable error.code, NEVER on the status alone (a client that assumes 409 means "a session is already running" will offer a force-end remedy that cannot help, succeeds at ending nothing, and loops):

• active_sim_session — the agent already has a pending/running/paused session. error.details.session_id carries the BLOCKING session's id so the client can stop that session directly. It is omitted (no details at all) on the DB unique-constraint backstop path, where a concurrent create raced the pre-check and the racing session's id is not known.
• dojo_provider_key_missing — no dojo provider key resolves for the agent's provider. An admin must set it (/admin/dojo) and the agent must be bound to its Try-Me config. Force-ending sessions does nothing for this.
• agent_unnamed — agents.name is empty for this agent, and the sim needs a name to spar as it. Remedy: PUT /v1/agents/{id} with {"name": "…"} (2-32 chars, letters/digits/hyphens), then retry. Names are normally written at birth from the gateway's x-mnemom-agent header, but birth is NOT the only writer — do not send the operator back through birth for an agent that already exists. Force-ending sessions does nothing for this.

An unrecognised or absent code on a 409 should fall back to displaying error.message verbatim rather than assuming any of the above.

Every spar turn is charged in µ to the agent's billing account, so Begin Sim first reads that account's balance from billing (plans do not matter): no µ billing account → 402 dojo_billing_unconfigured, balance at or below zero → 402 dojo_balance_depleted (both carry error.details.top_up_url, the deployment's web app billing page — https://www.mnemom.ai/settings/billing in production — and a plain error.message starting "Out of µ — recharge at <that page>."), billing unreachable → 503 dojo_balance_unverified (fail closed). No session is created in any of these cases. The runner re-reads the balance before each turn (a funded read is trusted for 30 seconds) and the gateway checks every agent call, so a run that runs out of µ mid-session stops at once, before another Agent Smith turn, and completes with outcome.ended balance_depleted or billing_unconfigured (or billing_unverified when the balance could not be checked: try again in a minute), after one system rating SimEvent carrying ended, message and top_up_url. Other gateway refusals of the agent's call also end the run at once, with their own ended and a plain message but no top_up_url (recharging is not the remedy): account_suspended (a suspended account), billing_refused (any other billing refusal), and dojo_refused (a Dojo rule: 403 dojo_claim_required, or 400 dojo_model_unpinned / dojo_model_not_allowed / dojo_max_tokens_exceeded / dojo_invalid_body / dojo_multiple_completions).