security(sandbox): Docker unreachable silently downgrades to uncontainerized host execution — hardening drops with no signal #17265

Problem

When the Docker daemon is unreachable, code execution silently falls back to uncontainerized subprocess execution on the host. The security posture changes and nothing says so.

autobot-backend/api/sandbox_health.py computes _docker_sdk_present and _daemon_reachable, and documents that the main compose deployment can fall back to LocalBackend when Docker is not reachable.

The containerized path applies real hardening — network_mode: "none", read_only: True, security_opt: ["no-new-privileges"], cap_drop: ["ALL"], memory and CPU limits (autobot-backend/secure_sandbox_executor.py:735-756). The fallback path has none of it. The difference between "sandboxed" and "a subprocess on the host" is invisible to the caller.

Why it matters more on a hardened or air-gapped host

Exactly the deployments most likely to have a restricted or absent Docker daemon are the ones least able to tolerate a silent downgrade to host execution. #17226's acceptance criteria already argue the principle for model artefacts — fail loudly with a named missing artefact rather than attempting a fetch. The same rule should hold for capability degradation, not just missing files.

Acceptance criteria

• Falling back from containerized to uncontainerized execution is an explicit, logged, operator-visible state — never silent
• The fallback is opt-in by configuration, or refuses by default, rather than being automatic
• An API response from the degraded path states which isolation guarantees are not in effect
• A health surface distinguishes "sandboxed execution available" from "executing on the host"
• A test asserts the daemon-unreachable case does not silently execute uncontainerized

Refs #17226.