IsolationSession: a second deprovision reports success instead of stale_id #1429

Relevant area(s)

Windows

Brief description of your issue

Calling deprovision twice on the same IsolationSession sandboxId succeeds both times. The second call should fail with error.code: "stale_id", because by then the agent user it is meant to remove is already gone.

Every other lifecycle operation gets this right. Running start, stop, or exec against a deprovisioned sandboxId correctly returns stale_id with nativeCode: "0x80070490". Only deprovision reports success.

This matters because stale_id is how a caller learns that a sandboxId is dead. A caller that retries a deprovision it is unsure about — which the docs actively recommend as a best-effort cleanup pattern — gets a success back and has no way to tell whether it cleaned anything up or operated on nothing at all.

Steps to reproduce

1. provision an IsolationSession sandbox and keep the returned sandboxId.
2. deprovision it. This succeeds.
3. deprovision the same sandboxId again.

Covered by two scenarios in tests/scripts/run_isolation_session_state_aware_tests.ps1:

• stale_id (deprovision on previously-deprovisioned sandbox)
• Lifecycle G: repeating deprovision reports a stale sandbox

Both fail identically on all four isolation-session jobs (prerelease-26h1 and prerelease-isolation-session, x64 and arm64) in https://github.com/microsoft/mxc/actions/runs/37522853336, so this is deterministic rather than flaky.

Expected behavior

The second deprovision fails with a non-zero exit code and an error envelope carrying:

• error.code: "stale_id"
• error.operation naming the failing API call (IsoSessionOps.*)
• error.nativeCode: "0x80070490" (HRESULT_FROM_WIN32(ERROR_NOT_FOUND))

This is the documented contract in two places:

• docs/isolation-session/state-aware-rust.md:404 — "A second deprovision on the same sandboxId fails the OS-side agent-user lookup (HRESULT_FROM_WIN32(ERROR_NOT_FOUND)), which the runner maps to MxcError::StaleId."
• docs/state-aware-lifecycle/mxc-state-aware-sandbox-api.md:1804 — "deprovision either succeeds (cleanup completes) or returns stale_id."

Actual behavior

The second deprovision exits 0 with an empty error:

FAIL: exit code is non-zero (deprovision on a stale sandbox failed as expected)
FAIL: error.code is 'stale_id' (got '')
FAIL: a second deprovision does not report success

The MXC-side plumbing looks correct, so the break appears to be below it. IsolationSessionBackend::deprovision (src/mxc-sdk/src/backends/isolation_session/common/state_aware.rs:171) calls straight through to deprovision_agent_user with no short-circuit, and that call already classifies with StalePromotion::Eligible (manager.rs:674-680). So the ERROR_NOT_FOUND → stale_id promotion is wired up and would fire — which suggests the underlying RemoveUser call is returning success for an agent user that no longer exists, leaving nothing to promote.

Worth confirming where the chain actually breaks before picking a fix, since the options differ a lot:

• have MXC detect the missing agent user itself and raise stale_id,
• get the OS API to report ERROR_NOT_FOUND (cross-repo), or
• decide deprovision is idempotent on purpose and update the docs and tests to match.