[Ubuntu 24.04][Sandbox] nemoclaw start misdiagnoses Docker-daemon-unreachable as a removed container, suggests destructive rebuild

## Description

When the Docker daemon is unreachable, `nemoclaw {sandbox} start` misdiagnoses this as the sandbox's container having been removed and suggests running the destructive `rebuild` command, instead of identifying the documented `host.docker.daemon_unreachable` condition and telling the user to restart Docker.

Platform scope: Reproduced on Ubuntu 24.04 x86_64 only; other platforms not tested.
Regression: Unknown — earlier versions not tested for this specific scenario.
OpenShell issue: No

## Environment

```text
Device: Ubuntu 24.04 x86_64 test host (Docker driver)
OS: Ubuntu 24.04.4 LTS
Architecture: x86_64
Node.js: v22.23.0
npm: 10.9.8
Docker: Docker version 29.7.2, build a7dcaa6
OpenShell CLI: 0.0.106
NemoClaw: v0.0.123
OpenClaw: 2026.7.1
```

## Steps to Reproduce

1. Onboard a healthy OpenClaw sandbox and confirm it is Ready:
```bash
nemoclaw onboard --name {sandbox} --agent openclaw --non-interactive --yes
nemoclaw {sandbox} status
```

2. Stop the sandbox intentionally:
```bash
nemoclaw {sandbox} stop
```

3. Stop the Docker daemon through the documented service control (both the service and its socket unit, since socket activation otherwise silently restarts dockerd on the next docker command):
```bash
sudo systemctl stop docker
sudo systemctl stop docker.socket
```

4. Confirm Docker is genuinely unreachable:
```bash
docker ps
# returns: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
```

5. Attempt to start the sandbox:
```bash
nemoclaw {sandbox} start
```

6. Restart Docker and inspect whether the container was actually ever removed:
```bash
sudo systemctl start docker
docker ps -a --filter "name={sandbox}"
```

## Expected Result

Per the public troubleshooting docs (docs.nvidia.com/nemoclaw), NemoClaw is documented to recognize this exact condition: "A `host.docker.daemon_unreachable` finding means Docker is installed but NemoClaw cannot reach the daemon," with the recommended action "start the Docker daemon: `sudo systemctl start docker`." Step 5 should surface this finding and tell the user to restart Docker, not claim the container is missing.

## Actual Result

Step 5 output:

```text
Could not start sandbox '{sandbox}': no Docker container labeled
'openshell.ai/sandbox-name={sandbox}'. If the container was removed, run
'nemoclaw {sandbox} rebuild' to recreate it.
```

This never mentions Docker/the daemon being unreachable, and instead suggests `rebuild`, a destructive recreate operation.

Step 6 confirms the container was never removed — restarting Docker brings the exact same container back healthy immediately, and the sandbox recovers cleanly via `nemoclaw {sandbox} recover` with its workspace data intact:

```text
CONTAINER ID STATUS NAMES
dd4fb75209b8 Up 14 seconds (healthy) openshell-default--{sandbox}-{id}
```

So the "container was removed" diagnosis in step 5 is simply false — the real condition is that NemoClaw could not reach Docker at all, which is the documented `host.docker.daemon_unreachable` case.

## Logs

Not captured — the Docker-daemon-down window doesn't produce any relevant NemoClaw gateway log lines (the daemon check fails before the gateway can log anything about the sandbox); the full CLI output is reproduced verbatim in Actual Result above.