bug(compute-driver): lifecycle RPCs carry a name field that cannot identify a sandbox

Start with the lifecycle request definitions in proto/compute_driver.proto, then read DriverSandbox.workspace and the ComputeManager::stop_sandbox call site in crates/openshell-server/src/compute/mod.rs. Review #3253, #3254, #3278, and #3305 before determining the contract direction. Done means the four lifecycle requests and ListSandboxesRequest are consistent, the rationale is documented, and a two-workspace same-name regression protects at least one driver.

User Story

As a compute-driver implementer, I want the driver-facing lifecycle RPCs to carry a sandbox reference sufficient to identify exactly one sandbox, so that I do not have to choose between trusting sandbox_id blindly and resolving an ambiguous name.

Problem Statement

StopSandboxRequest, StartSandboxRequest, DeleteSandboxRequest, and GetSandboxRequest in proto/compute_driver.proto carry {sandbox_id, name}. The name field is the plain sandbox name (object_name()), which is unique per workspace, not globally. No workspace accompanies it, so name alone cannot identify a sandbox.

This is inconsistent with the rest of the same contract:

Driver RPC	Carries workspace
CreateSandbox	Yes, via DriverSandbox.workspace
EnsureWorkspace / DeleteWorkspace	Yes, workspace
GetSandbox	No
StopSandbox	No
StartSandbox	No
DeleteSandbox	No
ListSandboxes	No (empty request)

DriverSandbox.workspace (proto/compute_driver.proto:163-165) is documented as "Used by drivers to construct collision-safe resource names and labels in shared-namespace mode." The contract therefore supplies workspace at create time specifically for collision safety, then withholds it on every subsequent lookup of the same resource.

The gateway holds the workspace at each of these call sites. ComputeManager::stop_sandbox(workspace, name) uses it to resolve the sandbox from the store, then constructs StopSandboxRequest { sandbox_id, name: sandbox_name } without it (crates/openshell-server/src/compute/mod.rs:1239, call site at :1346).

Impact / Why This Matters

Two drivers shipped the predictable bug. #3254 (VM) and #3253 (MXC) both fell back to name-only resolution when sandbox_id was absent, and both could act on a same-named sandbox in another workspace. These were fixed in #3305 and #3278 by making sandbox_id strictly authoritative.

Docker, Podman, and Kubernetes avoided the same bug only incidentally, by threading workspace into runtime identity at create time (container_name(workspace, name, id), managed_namespace(gateway_id, workspace)). That is a per-driver convention, not a contract guarantee. VM and MXC key their registries on id alone, which is why they were the two affected drivers.

The current workaround — id-authoritative resolution implemented separately in each driver — fixes the two known instances. It does not prevent the next driver from reading name and reaching the same conclusion, because the field is still present and still appears usable.

proto/compute_driver.proto is explicitly a gateway/compute-driver extension contract for independently versioned external drivers. An external implementer reading {sandbox_id, name} has no way to learn that name is insufficient, and no workspace available to reconcile or garbage-collect platform state against.

Acceptance Criteria

• A decision is recorded on whether the driver lifecycle sandbox reference is ID-only or (sandbox_id, workspace, name).
• StopSandboxRequest, StartSandboxRequest, DeleteSandboxRequest, and GetSandboxRequest reflect that decision consistently.
• ListSandboxesRequest is addressed under the same decision.
• proto/compute_driver.proto documents why the driver boundary differs from the public (workspace, name) contract, per proto/README.md conventions.
• At least one driver enforces the resulting contract with a regression covering two workspaces that share a sandbox name.
• The id-authoritative fixes in #3305 and #3278 remain correct under the chosen option.

Reproduction Steps

This is a contract defect rather than a runtime failure on current main; both known runtime instances are now fixed. To observe the underdetermined reference:

1. Read message StopSandboxRequest at proto/compute_driver.proto:398. It declares sandbox_id and name only.
2. Read DriverSandbox.workspace at proto/compute_driver.proto:163-165, supplied to CreateSandbox for collision-safe naming.
3. Read ComputeManager::stop_sandbox at crates/openshell-server/src/compute/mod.rs:1239. It receives workspace, resolves the sandbox with get_message_by_name::<Sandbox>(workspace, name), then builds the driver request at :1346 without the workspace.
4. Create two sandboxes with the same name in different workspaces. The driver receives the same name value for both; only sandbox_id distinguishes them.

For the empirical form of the defect, see the pre-fix behavior described in #3253 and #3254.

Environment

• OpenShell: main at 7139df8ca
• OS: not environment-specific
• Runtime, deployment, or integration: proto/compute_driver.proto extension contract; observed in openshell-driver-vm and openshell-driver-mxc, contract applies to all compute drivers

Notes

Two coherent resolutions exist and this issue does not choose between them:

Option A — drop name. Make these RPCs ID-only. sandbox_id is globally unique and stable, which is sufficient for lookup and consistent with the "immutable IDs remain internal to compute-driver boundaries" line drawn in #3050/#3272. Drivers needing a human-readable name already receive it at create.

Option B — complete the reference. Add workspace to the four requests, populated from the record the gateway has already resolved. sandbox_id stays authoritative for lookup; (workspace, name) becomes a complete secondary reference for reconciliation, labelling, and cross-checking.

Surface ownership sits with @drew, who is currently considering the compute-driver direction. This issue records the inconsistency and the open decision; it does not propose a resolution.

Parent: #2565, which scopes extension contracts including compute drivers. #3050 (closed by #3272) performed the equivalent review for the public gateway RPCs and standardized them on (workspace, name); the compute-driver surface was intentionally left on internal IDs and has not been revisited since.

Related: #3253, #3254, #3278, #3305.