feat: add probe, preflight, capability fields, and driver selection for launched drivers #5387

Part of #5200 and #5384.

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. Features the gateway checks today through in-process Rust methods must be answerable by an external driver.

Problem Statement

The gateway uses in-process factory methods for availability (is_available), config validation (validate_config), host-tool checks (preflight_host_tools), network trust support (supports_network_supervisor_trust), and shared supervision (uses_shared_supervision). A process the gateway launches cannot be asked through a Rust trait. Today, additional CA trust and the shared supervisor pool are rejected outright for external drivers.

Impact / Why This Matters

If Docker and Podman become launched drivers without these answers, auto-detection, config validation, and additional CA support regress for default installs.

Proposed Design

Add driver subcommands that take the startup document and print a bounded JSON result:

• probe reports whether the driver is usable on this host and why not. It replaces is_available.
• preflight validates driver config and checks host tools without starting runtime state. It replaces validate_config and preflight_host_tools, keeping their rules: bounded time and output, cleanup on cancellation, and operator-readable results including executable paths.

Add two capability fields to GetCapabilities: whether the driver propagates the gateway's network supervisor trust bundle, and whether the configured driver uses shared supervision. The gateway refuses a driver whose protocol version it cannot speak, with an error naming both versions.

Driver selection: core keeps an ordered table of built-in driver names with detection priority, telemetry category, and whether the driver is auto-detected. When no driver is configured, the gateway runs each auto-detected driver's probe in priority order and picks the first available one. Today that is Kubernetes (100), Podman (200), and Docker (300). VM stays explicit-only, as documented. probe reports availability only, so selection policy stays in core.

Decisions needed (before implementation)

Do not implement until this is resolved. The recommendation is a proposal; reviewers can override it.

1. When does the gateway ask the two capability questions?
   • Current behavior: both are static factory methods answered before any driver is built. Network trust is checked in resolve_configured_compute_driver (crates/openshell-server/src/lib.rs), only if the operator configured additional CA trust. Shared supervision is checked in validate_supervisor_pool_consumer, only if the gateway config has a supervisor_pool table, and for Kubernetes the answer depends on the driver's config.
   • Constraint: for a launched driver the answer comes from the driver, and gateway package preflight today validates config without constructing a driver or connecting.
   • Options: (a) preflight returns both answers, so they are available before launch; (b) launch the driver and read them from GetCapabilities, then validate before serving; (c) a static manifest in core, which cannot express the config-dependent shared-supervision answer.
   • Recommendation: (b). GetCapabilities is the single source of truth, each check runs only when its feature is configured, and the existing error messages are kept. Consequence: package preflight cannot check these two combinations for launched drivers without launching them.

Acceptance Criteria

• The decision above is recorded in this issue.
• Auto-detection picks the same driver as before on a host with the same set of runtimes. The existing registry tests are the starting point.
• A probe that fails, times out, or prints oversized output counts as not available and is reported by name, so detection never hangs on one broken driver.
• The VM driver stays explicit-only.
• probe and preflight have bounded time and output.
• A driver with an incompatible protocol version is refused with an error naming both versions.
• The existing additional-CA and supervisor-pool errors are preserved for drivers that do not report support.
• Tests use a fake available driver, since VM is not auto-detected.

Alternatives Considered

• A static manifest of capabilities in core. Cannot express the shared-supervision answer, which depends on driver config.
• Let probe carry the auto-detect policy. Moves a core behavior into a driver binary that may live in another repository, and conflates availability with selection.

Agent Investigation

• ComputeDriverRegistration carries name, detection_priority, detect: Option<fn() -> bool>, the factory, telemetry_category, and in_process_tracing. VM is registered with detect: None and priority u16::MAX, so it is never auto-detected.
• The docs state that the VM driver is never auto-detected (docs/how-it-works/sandboxes/runtimes.mdx).
• Kubernetes keeps its in-process environment check, since it does not move.