[DGX Station][Sandbox] connect refuses a foreign-workspace container correctly but reports only a generic Error state, never naming the workspace or identity boundary

## Description

When the only container matching a sandbox name carries a foreign `openshell.ai/sandbox-workspace` value, `nemoclaw SANDBOX connect` correctly refuses to reuse it and exits non-zero. The refusal itself is right. What is missing is any statement of why.

The entire diagnostic is:

```text
Sandbox 'SANDBOX' is in 'Error' state.
Run: nemoclaw SANDBOX logs --follow
Run: nemoclaw SANDBOX status
```

A grep of the full output for workspace, identity, foreign, or "cannot be matched" returns zero matches. The user is told the sandbox is broken, not that a container belonging to a different workspace was found and rejected, so the two suggested follow-up commands send them to look for a runtime fault that does not exist.

This is the opposite half of an already-fixed defect. That one was about the same condition not failing closed; this one is about it failing closed silently. The safety behaviour is now correct and only the explanation is missing.

Constructed so the product is actually asked the question: the real container was stopped and renamed out of the way, and the only container left carrying `openshell.ai/sandbox-name=SANDBOX` was an impostor labelled `openshell.ai/sandbox-workspace=other-workspace`. The real sandbox's own workspace label is `default`, so the two genuinely differ.

Worth noting for whoever fixes this: simply renaming the real container, which is what a natural reading of "simulate a foreign workspace" suggests, does not change any label and does not create this condition. The impostor container has to be created with the foreign workspace label.

Platform scope: Reproduced on DGX Station GB300 (aarch64, Ubuntu 24.04); other platforms not tested.
Regression: Unknown - earlier versions not tested for this path.

## Environment

```text
Device: DGX Station GB300
OS: Ubuntu 24.04 LTS
Architecture: aarch64
Node.js: v22.23.2
npm: 10.9.8
Docker: 29.2.1
OpenShell CLI: 0.0.106
NemoClaw: v0.0.118
OpenClaw: 2026.7.1
```

## Steps to Reproduce

```bash
# 1. Onboard a healthy OpenClaw sandbox and confirm its labels
nemoclaw onboard --name SANDBOX --agent openclaw --non-interactive --fresh --yes
CID=$(docker ps -q --filter "label=openshell.ai/sandbox-name=SANDBOX" | head -1)
docker inspect --format '{{index .Config.Labels "openshell.ai/sandbox-workspace"}}' $CID

# 2. Stop the sandbox and move the real container aside, keeping its original name
nemoclaw SANDBOX stop
docker container rename $CID parked-SANDBOX

# 3. Leave only an impostor carrying a FOREIGN workspace qualifier
docker run -d --name impostor-SANDBOX \
--label openshell.ai/sandbox-name=SANDBOX \
--label openshell.ai/sandbox-workspace=other-workspace \
busybox:latest sleep 3600

# 4. Attempt to reuse the sandbox and capture the full output
nemoclaw SANDBOX connect

# 5. Search that output for the boundary that was enforced
grep -Ei 'workspace|identity|foreign|cannot be matched'

# 6. Restore: remove the impostor, rename the real container back, start again
```

## Expected Result

connect exits non-zero and its output says why: that a container matching this sandbox name belongs to a different workspace, or that no container could be matched to the current workspace identity.

A user reading the message can tell that this is an ownership boundary being enforced, not a crashed sandbox, and is not sent to logs and status to investigate a runtime fault.

## Actual Result

```text
Setup, verified before the attempt:

real container openshell.ai/sandbox-name=SANDBOX
openshell.ai/sandbox-workspace=default (renamed aside)
impostor openshell.ai/sandbox-name=SANDBOX
openshell.ai/sandbox-workspace=other-workspace

The attempt:

nemoclaw SANDBOX connect exit 1

Active gateway set to 'nemoclaw'
Waiting for sandbox 'SANDBOX' to be ready...

Sandbox 'SANDBOX' entered 'Error' state.
Run: nemoclaw SANDBOX logs --follow
Run: nemoclaw SANDBOX status

Mentions of workspace, identity, foreign, or "cannot be matched": 0

After restoring the original container name the sandbox starts and reports
healthy again, confirming the sandbox itself was never faulty:

start exit 0
status exit 0

Control, same host: with the real container present and healthy AND a
foreign-workspace container also present, status exits 0 and the foreign one is
correctly ignored rather than treated as ambiguous. So the workspace scoping
works; only the refusal path's message is uninformative.
```