bug: sandbox --label values are stored as metadata but never applied to the pod/container

Agent Diagnostic

Pointed an agent at the repo and traced the create-sandbox label flow across the gateway and compute drivers (codebase exploration + openshell-cli knowledge).

• openshell sandbox create --label k=v sends the label in CreateSandboxRequest.labels (crates/openshell-cli/src/main.rs → run.rs::sandbox_create).
• In the gateway, handle_create_sandbox_inner (crates/openshell-server/src/grpc/sandbox.rs) stores those labels only in ObjectMeta.labels (sandbox metadata used for CLI filtering / --selector). They were never copied into SandboxTemplate.labels.
• SandboxTemplate.labels is the backend-neutral field documented as "Labels applied to compute-platform resources", mapped to DriverSandboxTemplate.labels in crates/openshell-server/src/compute/mod.rs (driver_sandbox_template_from_public).
• Drivers consume template.labels: the Kubernetes driver applies them to pod metadata (crates/openshell-driver-kubernetes/src/driver.rs), the Docker driver to container labels (crates/openshell-driver-docker/src/lib.rs). The VM driver ignores them.
• Root cause: the CLI never populates template.labels, and the gateway never bridges request.labels → template.labels. So there was no path for a user-supplied --label to reach the pod/container; it only ever became sandbox metadata.

Description

Actual behavior: openshell sandbox create --label env=dev records env=dev as sandbox metadata (visible via openshell sandbox list --selector env=dev), but the label is not applied to the underlying Kubernetes pod (or Docker container). kubectl get pods -l env=dev returns nothing.

Expected behavior: User-supplied labels are applied to the underlying compute resource (pod / container) in addition to being stored as sandbox metadata, so operators can select the workload with native platform tooling.

Reproduction Steps

1. Register/select a Kubernetes-backed gateway.
2. openshell sandbox create --label env=dev -- claude
3. kubectl get pods -l env=dev -n <sandbox-namespace>
4. Observe: no pod matches the label, even though openshell sandbox list --selector env=dev shows the sandbox.

Environment

• OS: any (code-level bug, platform-independent)
• Compute driver: Kubernetes (Docker affected the same way; VM driver has no label support)
• OpenShell: main branch

Logs

No error is emitted — the labels are silently confined to sandbox metadata.

Agent-First Checklist

• I pointed my agent at the repo and had it investigate this issue
• I loaded relevant skills (e.g., openshell-cli) and traced the create-sandbox flow across the gateway and compute drivers
• My agent could not resolve this without a code change — the diagnostic above explains the root cause and fix location

Trace the create flow from crates/openshell-cli/src/main.rs and run.rs::sandbox_create into handle_create_sandbox_inner in crates/openshell-server/src/grpc/sandbox.rs. Then inspect driver_sandbox_template_from_public in crates/openshell-server/src/compute/mod.rs and the Kubernetes and Docker driver label handling. Done means a user-supplied label remains sandbox metadata and is also applied to the underlying pod or container.