feat(gateway): build Dockerfile sandbox images through the selected runtime

[krishicks]

User Story

As an OpenShell user creating a sandbox from a local Dockerfile,
I want the gateway to build the image using its selected compute runtime,
so that the image is available to the sandbox without separately configuring or accessing the runtime from the CLI host.

Problem Statement

openshell sandbox create --from <Dockerfile-or-directory> currently builds through a Docker-compatible daemon selected by the CLI, assigns a local openshell/sandbox-from:<timestamp> tag, and sends only that tag to the gateway. The gateway independently selects and configures exactly one compute driver and expects the image to exist in that driver's image store.

This duplicates runtime selection across the CLI and gateway. Since cf4deccd3, gateway auto-detection and Docker driver initialization use responsive-socket probing through detect_docker_socket(); Podman similarly uses detect_podman_socket(). The Dockerfile build path still uses Bollard's connect_with_local_defaults(), so it can build into a different image store than the gateway uses. The mismatch also occurs when the gateway explicitly selects a driver or configures a non-default socket.

OpenShell lacks a gateway-owned workflow for building a local Dockerfile into the image store associated with the selected compute driver.

Impact / Why This Matters

Without this feature, users must ensure that the CLI's Docker-compatible endpoint and the gateway's configured runtime happen to reference the same image store. A build can succeed but sandbox provisioning can still fail because the gateway cannot resolve the generated local tag.

Users working with Podman or non-default runtime endpoints must discover and align the engine API themselves or add runtime-specific build and image-import logic around OpenShell. This duplicates information already owned by the gateway, makes otherwise identical sandbox creation workflows depend on host runtime details, and prevents local Dockerfile support from behaving consistently across Docker and Podman gateways.

Previous client-side image export and gateway-container upload implementations produced memory and transport failures for large images, including #485, #600, #602, #655, and #674. Reintroducing an image archive round trip would retain those operational costs.

Proposed Design

Keep the existing user-facing workflow:

openshell sandbox create --from ./Dockerfile
openshell sandbox create --from ./directory

For a gateway and compute driver that support local Dockerfile builds, the CLI sends the Dockerfile build context to the gateway. The gateway builds the image using the runtime endpoint associated with its selected compute driver, streams build progress back to the CLI, and creates the sandbox from the resulting image identity.

Users should not need the Docker or Podman CLI, direct access to a container-engine socket, or duplicate engine configuration on the CLI host. The build result must be placed in an image store the selected driver can resolve. Explicit gateway driver and socket configuration must take precedence over auto-detection.

When the selected driver does not support gateway-local builds, OpenShell should return an actionable error directing the user to provide a registry image reference. The design should leave room for registry-backed builders and remote or Kubernetes gateways without requiring them in the initial implementation.

Acceptance Criteria

• openshell sandbox create --from <Dockerfile> builds and starts a sandbox on a local Docker gateway without the CLI independently selecting a Docker endpoint.
• The same command builds and starts a sandbox on a local Podman gateway without requiring Podman-specific build or image-load orchestration by the caller.
• The image is built into, or otherwise made directly available to, the image store used by the gateway's selected compute driver.
• Explicit compute-driver and runtime-endpoint configuration is honored; the CLI cannot silently build into a different locally detected image store.
• Build progress and build failures are reported through the existing sandbox creation workflow.
• Unsupported compute drivers receive an actionable error that recommends a registry image reference.
• The workflow does not export a complete image archive through the CLI and then upload it into a gateway container.
• Documentation explains which gateway and driver configurations support local Dockerfile builds.

Alternatives Considered

Reuse driver auto-detection in the CLI. The CLI could query the selected driver name and call detect_docker_socket() or `detect_podman_socket()). This improves the auto-detected case but remains incorrect for explicit socket configuration, differing process environments, and gateway/CLI filesystem namespaces.

Expose the gateway's runtime socket path to the CLI. This would let the CLI build against the configured endpoint, but it exposes a privileged implementation detail and assumes the path is meaningful and accessible from the CLI process.

Push every local build to a registry. A registry is the portable distribution boundary for remote, Kubernetes, and multi-host gateways, but requiring registry configuration and credentials would make the existing local development workflow significantly heavier. Registry-backed builds remain a useful future extension.

Build and export on the client, then import through the gateway. OpenShell previously used image archive export/upload paths. Large images caused excessive memory use and transport failures, and the image crossed the client boundary unnecessarily.

Agent Investigation

• crates/openshell-cli/src/run.rs resolves a Dockerfile, builds it locally, and passes only the generated tag in the sandbox template.
• crates/openshell-bootstrap/src/build.rs connects with Docker::connect_with_local_defaults().
• crates/openshell-core/src/config.rs selects one driver and probes responsive Docker and Podman sockets through detect_docker_socket() and detect_podman_socket().
• crates/openshell-driver-docker/src/lib.rs uses explicit Docker socket_path configuration or the shared Docker detector.
• crates/openshell-driver-podman/src/driver.rs uses explicit Podman socket_path configuration or the shared Podman detector.
• GetGatewayInfo already reports the gateway's single initialized compute driver, but the current Dockerfile build path does not use that selection.
• architecture/compute-runtimes.md assigns image selection and runtime-owned provisioning to compute drivers while the gateway owns the public sandbox lifecycle.
• Reviewed related issues feat(cli): add --from flag to sandbox create for unified image sources #88, openshell sandbox create --from <Dockerfile> fails with timeout when the resulting image is large (e.g., 2.5 GB). #485, openshell sandbox create --from OOM-killed on large images due to in-memory image buffering #600, bug: openshell sandbox create --from OOM-killed on large images #602, openshell sandbox create --from allocates unbounded memory during image push, scaling to consume all available RAM #655, sandbox create --from Dockerfile fails uploading image tar into gateway container on macOS #674, bug: resolve_from() silently treats non-existent paths as image references #751, feat(cli): investigate sandbox specs and openshell apply -f #1520, feat: support rootfs tar as --from source for VM driver sandboxes #2175, and Add support for Containerfile named files for sandbox creation. #2420; none covers gateway-owned Dockerfile builds into the selected driver's image store.

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request