feat(docker): support host and bridge supervisor networking

[drew]

Summary

The Docker supervisor previously required host networking. Add an operator-owned supervisor_network_mode setting so deployments can explicitly use host or bridge networking. Host remains the default, and auto selects host.

Bridge callbacks preserve explicit endpoints and TLS verification. Docker's actual host address is discovered automatically once when the driver starts, so Desktop deployments do not confuse the VM's bridge gateway with the host. All runtime changes are confined to the Docker driver; the supervisor is unchanged.

Related Issue

Related to #4015. Automatic ECI mode selection and ECI sandbox-runtime compatibility remain outside this PR's scope.

Changes

• Support host and bridge supervisor networking while retaining network=none and the existing isolation requirements for workloads.
• For bridge mode or a gateway endpoint using host.docker.internal, resolve Docker's host-gateway once during driver construction and cache the IP for all sandbox launches.
• Use Docker API calls to create a temporary container from the immutable supervisor image, run --help, wait for exit, and download Docker's generated /etc/hosts through the archive endpoint. No shell or docker exec is used.
• Confine the resolver with no network, all capabilities dropped, no privilege escalation, and a read-only root filesystem. Bound discovery to 30 seconds and perform forced cleanup after success or failure with a separate 10-second timeout.
• Use the same validated IP for host aliases and the runtime descriptor's host trust pin. An explicit operator-owned host_gateway_ip remains an optional override that skips discovery.
• Update configuration/runtime docs, the local Docker launcher, and operational guidance, including OTLP endpoint reachability.

Validation

• Docker driver library tests: 144 passed, 2 opt-in live tests ignored by default.
• Opt-in Docker API resolver integration test passed on Docker Desktop: discovered 192.168.65.254 and verified no resolver container remained after either successful discovery or a deliberately failed container start.
• Focused Docker driver Clippy, formatting, Markdown lint, and diff whitespace checks passed.
• The Docker Desktop sandbox capability probe still fails at seccomp notification qualification under the enabled ECI runtime. Full sandbox E2E remains blocked by that separate runtime limitation.

[copy-pr-bot]

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-4016.docs.buildwithfern.com/openshell

[github-actions]

Label test:e2e applied for 8f122f7. Open the existing run and click Re-run all jobs to execute with the label set. The run will execute the standard E2E suite after building the required gateway, sandbox, and supervisor images once. The matching required CI gate status on this PR will flip green automatically once the run finishes.

[TaylorMutch]

One non-blocking telemetry concern: bridge mode changes the reachability of loopback OTLP endpoints. This can be addressed here or in a separate follow-up fix if preferred.

I reviewed the full diff and surrounding code and verified the host-gateway alias mapping in a temporary Docker Desktop bridge container. I did not run the full test suite or validate ECI itself.