bug(driver-mxc): StopSandbox discards sandbox_id and can stop a same-named sandbox in another workspace

Comienza en crates/openshell-driver-mxc/src/grpc.rs, en StopSandbox y GetSandbox, y luego sigue backend stop_sandbox en crates/openshell-driver-mxc/src/driver.rs. Usa como contexto la prueba de nomenclatura con ámbito de workspace en crates/openshell-server/src/persistence/tests.rs y ejecuta las pruebas relevantes de Rust. Se considera terminado cuando las detenciones con ámbito de ID no pueden dirigirse a otra sandbox con el mismo nombre, las detenciones ambiguas basadas únicamente en el nombre fallan de forma determinista y DeleteSandbox ha sido auditado.

User Story

As an operator running sandboxes across multiple workspaces on the MXC driver, I want a stop request to act on exactly the sandbox the gateway identified, so that stopping a sandbox in one workspace never interrupts an unrelated sandbox that happens to share its name.

Problem Statement

StopSandbox on the MXC driver discards the sandbox_id it receives and resolves the target by name alone.

crates/openshell-driver-mxc/src/grpc.rs:124-128:

if req.sandbox_name.is_empty() {
    return Err(Status::invalid_argument("sandbox_name is required"));
}
self.backend.stop_sandbox(&req.sandbox_name).await?;

req.sandbox_id is never read. The backend then resolves by name (crates/openshell-driver-mxc/src/driver.rs:441):

let entry = registry
    .values()
    .find(|entry| entry.sandbox.name == sandbox_name)
    .ok_or_else(|| tonic::Status::not_found(format!("sandbox {sandbox_name} not found")))?;

Nothing verifies afterward that the resolved entry is the one the request named.

Sandbox names are unique per workspace, not globally (crates/openshell-server/src/persistence/tests.rs:684, sqlite_name_unique_scoped_by_workspace), so two sandboxes in different workspaces can legitimately share a name. The MXC registry permits this: create_sandbox rejects duplicates by id only (driver.rs:389), never by name. With two same-named entries present, HashMap::values().find(...) picks one by iteration order.

The driver already carries the information needed to disambiguate — SandboxEntry.sandbox.workspace is populated (driver.rs:877) — and the same file already demonstrates the missing guard. GetSandbox performs a post-resolution id check (grpc.rs:90):

if !req.sandbox_id.is_empty() && req.sandbox_id != sandbox.id {
    return Err(Status::failed_precondition("sandbox_id did not match the fetched sandbox"));
}

StopSandbox has no equivalent.

Impact / Why This Matters

The gateway always sends a valid sandbox_id on StopSandbox, so this misfires on ordinary traffic — no restart, retry, or unusual state is required. An operator stopping demo in one workspace can silently stop demo in another, terminating a live workload with no error surfaced to either caller. Which sandbox is hit depends on hash iteration order, so the failure is not reproducible run to run.

There is no workaround available to the caller: the request already carries the correct id and the driver ignores it. Avoiding the bug requires never reusing a sandbox name across workspaces on an MXC gateway, which contradicts the workspace-scoped naming the rest of the product guarantees.

Related: #3234 and #3240 address the same class of defect in the Docker driver.

Acceptance Criteria

• StopSandbox resolves the target using sandbox_id when the request supplies one, and does not fall back to the name in that case.
• A stop request carrying a valid sandbox_id never acts on a different sandbox that shares the sandbox_name.
• A name-only stop request that matches more than one sandbox fails with a deterministic error instead of selecting one by iteration order.
• Regression tests cover: id-scoped stop with two same-named sandboxes in different workspaces stops only the requested one; ambiguous name-only stop is rejected.
• DeleteSandbox on the same driver is audited for the same weakness (grpc.rs:145-155 forwards both fields; its backend path was not traced during this investigation).

Reproduction Steps

Code inspection; not reproduced against a running MXC gateway (Windows-only driver).

1. Create workspaces alpha and beta on a gateway using the MXC compute driver.
2. Create a sandbox named demo in alpha, and another named demo in beta. Both are accepted — names are unique per workspace, and the MXC registry rejects duplicates by id only.
3. Issue StopSandbox for the demo in beta. The gateway sends both that sandbox's id and the name demo.
4. Observe that the driver ignores the id and resolves demo by name, so the sandbox stopped may be the one in alpha.

Environment

• OpenShell: main at a0814443
• OS: Windows (MXC driver is Windows-only)
• Runtime, deployment, or integration: MXC compute driver, gateway with more than one workspace