[Ubuntu 22.04][CLI&UX] nemoclaw status never reports a DCode sandbox as ready after successful onboard

## Description

After a Deep Agents Code (DCode) sandbox onboards successfully, `nemoclaw status` never reports the sandbox as ready. Every invocation returns only the gateway-selection line with no readiness or state payload, so a caller polling status for readiness spins indefinitely instead of ever observing a terminal state.

- **Platform scope:** Reproduced on Ubuntu 22.04 only; other platforms not tested
- **Regression:** Unknown — earlier versions not tested in this triage round
- **OpenShell issue:** No — the status command that fails to report readiness is NemoClaw's own CLI layer, not the OpenShell CLI

## Environment

```text
Device: GitLab CI runner (ubuntu22 tag)
OS: Ubuntu 22.04
Architecture: x86_64
Node.js: v22.22.3
npm: 10.9.8
Docker: Docker version 29.4.0, build 9d7ad9f
OpenShell CLI: openshell 0.0.106
NemoClaw: nemoclaw v0.0.120
OpenClaw: N/A (DCode agent, not OpenClaw)
```

## Steps to Reproduce

1. On Ubuntu 22.04 with Docker installed, install NemoClaw and onboard a sandbox using the Deep Agents Code agent, e.g.:

```bash
nemoclaw onboard --non-interactive --agent langchain-deepagents-code --name --yes-i-accept-third-party-software
```

(with a valid NVIDIA inference credential configured)

2. Confirm onboarding completed successfully: `nemoclaw list --json` shows the sandbox present with `isDefault: true` and no incomplete-onboarding state.

3. Repeatedly invoke:

```bash
nemoclaw status
```

(poll on an interval, e.g. every 30-60 seconds, as any script waiting for the sandbox to become ready would)

## Expected Result

Each status call should complete quickly — well within the product's own declared OpenShell probe timeout of 15 seconds — and should report a definitive readiness/state payload for the sandbox once onboarding has finished, so a caller polling status can detect readiness and stop polling.

## Actual Result

Every status call returns only the gateway-selection line (`Active gateway set to ''`) with no sandbox readiness or state payload. Polling status this way continued for roughly 25 minutes across dozens of consecutive invocations — about 100x the product's own 15-second probe timeout — without a single call ever reporting the sandbox as ready.

The sandbox itself is not broken: `nemoclaw list` continues to show it active/default throughout, and `nemoclaw destroy --yes` completes normally afterward. Only the status command's readiness reporting for this sandbox is defective.

## Logs

```text
$ nemoclaw status
Active gateway set to 'nemoclaw'

$ nemoclaw status
Active gateway set to 'nemoclaw'

$ nemoclaw status
Active gateway set to 'nemoclaw'

$ nemoclaw status
Active gateway set to 'nemoclaw'

(pattern repeats identically across dozens of consecutive invocations spanning roughly 25 minutes; no readiness/state payload is ever printed on any call)
```

## Related issues — same family, not a duplicate

- #11054 / #11053 — `status` on a DeepAgents Code sandbox intermittently exits 1 with no diagnostic while still printing a full report. That failure mode is an occasional bad exit code with normal output; this one is a persistent complete absence of any readiness/state payload on every single call. Different symptom, same DCode + `status` area.

Start at the NemoClaw CLI entry point for `nemoclaw status` and compare its behavior with `nemoclaw list --json`, using the reproduction command and logs as the baseline. Trace the status path for a successfully onboarded DCode sandbox and verify that repeated calls return a definitive readiness or state payload within the declared 15-second probe timeout.

Written by the indexing model from the issue text.