Generalize read-only host mounts behind runtime-provider capabilities

[ericksoa]

Summary

Follow up on #8274 / #8280 by moving read-only host-mount support behind the runtime-provider contract instead of leaving it as an implicit Docker-only onboarding behavior.

The initial implementation is intentionally narrow: it validates host paths, emits OpenShell Docker bind-mount configuration, and enables the Docker-driver bind-mount gate only for Linux/WSL onboarding. That is the correct first backend, but the ownership boundary should be explicit before additional runtime providers become selectable.

Current gap

• --host-mount support is selected from host-platform checks rather than a runtime-provider capability.
• Docker bind-mount configuration is materialized centrally.
• The Docker gateway capability toggle is global and named for the backend.
• Kubernetes and the qualification-gated MXC bundle do not declare whether or why host-directory sharing is unsupported.
• A future provider could accidentally accept persisted host mounts without implementing equivalent read-only and path-safety guarantees.

Proposed direction

Add a provider-owned read-only host-mount capability/facet to RuntimeProviderBundle.

The contract should:

1. Bind support or an explicit unsupported reason to the provider identity.
2. Declare qualified host platforms separately from provider support.
3. Fail closed before session mutation or sandbox creation when the selected provider cannot honor requested or persisted mounts.
4. Keep the persisted declaration provider-neutral (source, target, readOnly, source identity).
5. Route provider-specific create configuration and any host-side activation through the selected provider boundary.
6. Preserve the final path/device/inode revalidation immediately before creation.

Initial support matrix:

Runtime provider	Status	Notes
Docker	Supported on Linux/WSL	Preserve the OpenShell bind-mount gate and read_only: true rendering from #8280.
Kubernetes	Explicitly unsupported	Do not infer hostPath; cluster/node locality, policy, and security semantics require a separately qualified design.
OpenShell MXC	Explicitly unsupported	Add the contract affordance, but do not claim support until OpenShell exposes and NemoClaw qualifies a native host-sharing contract.

Acceptance criteria

• Runtime-provider registration requires a read-only host-mount support declaration.
• Docker declares the currently qualified support; Kubernetes and MXC declare actionable unsupported reasons.
• CLI and resume/rebuild paths reject unsupported providers before durable state or runtime mutation.
• No unsupported provider silently falls back to Docker-shaped driver configuration.
• Provider-contract tests cover missing/malformed declarations and the support matrix.
• Onboarding tests cover supported, unsupported, and persisted-mount paths.
• Documentation includes the provider support matrix and a provider-author checklist for adding support.
• Writable host mounts remain out of scope.

First PR slice

Introduce the required provider capability declaration and fail-closed selection helper, wire the existing Docker implementation to it, and add explicit Kubernetes/MXC unsupported receipts. Provider-specific native mount implementations can then land independently without adding new onboarding branches.

Depends on #8280.

[ericksoa]

The first provider-capability slice is up in #8368, stacked on the Docker implementation in #8280. It adds the required support declaration, fail-closed CLI/resume checks, explicit Kubernetes/MXC unsupported reasons, tests, and the runtime support matrix. Native provider-specific materialization remains tracked here before this issue is complete.