test: add e2e coverage for external compute driver endpoints #1950

Description

Add end-to-end coverage for the remote compute-driver endpoint path introduced by the external compute driver socket work. The test should exercise a real standalone driver process connected to the gateway through the named remote-driver configuration path, rather than only the in-process/fake UDS unit coverage.

Context

This branch adds gateway support for selecting a non-reserved compute driver name and connecting it to a Unix domain socket endpoint. Unit coverage now verifies the gateway remote adapter with a fake UDS ComputeDriverServer, including GetCapabilities, ValidateSandboxCreate, CreateSandbox, and DeleteSandbox forwarding.

The remaining gap is an e2e test that proves the behavior with a real driver binary. Current e2e buckets include Docker, Podman, Kubernetes, GPU, and a local/manual VM bucket. The VM e2e wrapper already has the runtime setup needed for the VM driver, but the default branch e2e workflows do not currently run VM e2e. Podman and Kubernetes have standalone driver binaries, but they currently bind TCP; the gateway remote endpoint path currently consumes UDS endpoints.

Proposed Approach

Start with the lowest-cost real-driver path:

• Prefer adding UDS listen support to openshell-driver-podman, then add an opt-in external-driver mode to the Podman e2e wrapper.
• The e2e should start openshell-driver-podman as a separate process, configure the gateway with a custom non-reserved driver name such as external-podman, and point [openshell.drivers.external-podman].socket_path at the driver UDS.
• Reuse the existing Podman smoke/lifecycle e2e test surface where possible.
• Keep this as an opt-in/manual or label-gated e2e bucket unless it proves stable enough for the standard branch e2e path.

A VM variant is also valid as a compatibility smoke because openshell-driver-vm already supports UDS, but it should remain gated due to libkrun/runtime setup and platform sensitivity.

Definition of Done

• A real standalone compute driver can be launched separately from the gateway and reached through the named remote-driver socket path.
• The e2e covers gateway startup and at least one sandbox create/delete lifecycle through the external driver path.
• The test uses a non-reserved driver name and verifies the gateway does not rely on built-in driver selection.
• The new e2e bucket is documented in tasks/test.toml and, if wired to CI, in the relevant branch e2e workflow/label help.
• The test leaves existing built-in driver e2e behavior unchanged.

Agent Investigation

• e2e:vm exists and runs e2e/rust/e2e-vm.sh, but it is local/manual and not part of the label-driven Branch E2E workflow.
• Standard Branch E2E currently covers Python Docker, Rust Docker, Rust Podman, Rust rootless Podman, and Kubernetes smoke.
• GPU and Kubernetes HA have separate label-gated workflows.
• openshell-driver-vm already supports --bind-socket, making it usable as a real external UDS driver.
• openshell-driver-podman and openshell-driver-kubernetes have standalone binaries, but currently expose --bind-address TCP rather than a UDS bind mode.
• openshell-driver-docker is library-only today, so it is not currently usable as a real external driver process without first adding a binary.