feat: move the desktop compute drivers to the ai-openshell/desktop repository #5200

User Story

As an OpenShell Maintainer I want the desktop drivers to exist in their own repository so that their ownership and maintenance can be considered separately to core OpenShell.

Problem Statement

The desktop compute drivers (Docker, Podman, and later the microVM driver) should live in their own ai-openshell/desktop repository with their own maintainers, CI, and releases, as RFC 0019 (#4426) proposes. They cannot move today because core is compiled against them.

OpenShell compiles the Docker and Podman compute drivers into the gateway binary. The gateway registers them through in-process factories behind the default in-tree-compute-drivers feature, and a few other crates depend on driver crates directly (for example openshell-supervisor-network on openshell-driver-vm, and openshell-driver-vm on openshell-driver-podman). The drivers also share a large amount of code with core through openshell-core and openshell-sandbox-backend.

As a result, the desktop drivers cannot be owned, tested, or released separately from core. RFC 0019 leaves the technical path and timing of the desktop migration open. The ai-openshell/desktop repository exists but only contains a README.

Related: #4425, the issue for RFC 0019. This issue covers the separately scoped migration work that #4425 defers until the repository layout is agreed.

Impact / Why This Matters

Desktop driver maintainers must work inside core's CI and release machinery, and core must build and qualify against every first-party driver. This blocks the repository split proposed in RFC 0019 and makes it harder for new maintainers to own the Docker, Podman, and microVM drivers.

The workaround today is to keep everything in one repository with shared ownership, which is the situation RFC 0019 is trying to change.

Proposed Design

Move Docker and Podman to ai-openshell/desktop, and the microVM driver after them. Because the gateway links Docker and Podman in-process today, the move first requires running them as separate driver processes that the gateway launches and talks to over the existing ComputeDriver gRPC contract.

From a user or operator point of view:

• Driver names, auto-detection order, and driver_config tables keep working. Configuration is validated by the driver instead of the gateway.
• A default laptop install still gets a working Docker or Podman gateway. The install paths (install.sh, Homebrew, DEB, RPM, snap) deliver a single versioned bundle that pairs a core release with a desktop release.
• The gateway refuses to use a driver whose protocol version it cannot speak, with an error that names both versions.
• Kubernetes-only deployments are unaffected.

For maintainers, the work is in two parts. Part A makes drivers external inside this repository: a generic launcher, a versioned startup document, probe and preflight commands, and a small driver SDK carved out of openshell-core. Part B moves the desktop drivers to their own repository and defines how core, desktop, and packages release together. The detailed design is in a draft RFC, which this issue asks maintainers to number.

Suggested UX (if applicable)

Notional driver commands, to be refined in the RFC:

openshell-driver-podman probe --config /run/openshell/driver-startup.json
# {"available": true, "executables": ["/usr/bin/podman"]}

openshell-driver-docker preflight --config /run/openshell/driver-startup.json
# {"valid": true, "executables": ["/usr/bin/docker"], "errors": []}

Existing gateway configuration for selecting a driver and for driver_config is unchanged.

Acceptance Criteria

• Docker and Podman live in ai-openshell/desktop with named maintainers, CI, and release automation.
• Core builds, tests, and releases without the Docker, Podman, or VM driver crates.
• desktop CI runs the core conformance harness against its drivers on a pinned core release.
• A laptop install through packages still produces a working Docker or Podman gateway from pinned core and desktop releases.
• Before the move, the gateway starts the Docker and Podman drivers as separate processes by default and passes the existing Docker and Podman e2e suites.
• A driver with an incompatible protocol or startup-document version is refused with an error naming both versions.

Alternatives Considered

• Keep one repository and delegate ownership with CODEOWNERS. Least work, but everyone still shares one repository and release machinery.
• A gateway binary built by desktop that links core's server crates and registers the drivers in-process. Avoids a launcher but makes the Rust factory trait a public API and produces two gateway binaries.
• A proto-only contract with no shared Rust code. Keeps core's crates private but duplicates constants shared with the supervisor, so drift fails at runtime.
• Separate user-visible versions for core and desktop. Simpler packaging, but moves the compatibility matrix onto users.

Agent Investigation

Findings from reading the repository:

• openshell-gateway registers drivers in install_default_compute_drivers() behind compute-driver-* features. The VM driver is already launched as a gateway-managed subprocess (crates/openshell-gateway/src/vm.rs, ManagedDriverProcess), and operator-managed external drivers are documented in docs/extensibility/drivers.mdx.
• proto/compute_driver.proto already carries protocol negotiation (PeerMetadata in GetCapabilities) and the admission policy match. Two capability fields are missing for hooks that exist only as Rust factory methods today.
• The drivers import about 23 openshell-core modules (dominated by sandbox_env) plus a small slice of openshell-sandbox-backend. This count covers import paths only and has not been traced transitively.
• No Rust crate is published from this repository today and deny.toml forbids git dependencies, so desktop would consume the driver SDK as a git dependency with an exception in its own configuration.