[Ubuntu 24.04][Sandbox] destroy refuses to remove a retained sandbox yet exits 0, and its remediation points at an OpenShell procedure that does not exist

## Description

Interrupting the interactive onboarding wizard with Ctrl-C while the sandbox is being created leaves a retained sandbox that the product then refuses to clean up, while telling the user that nothing else can proceed until it is cleaned up.

Three separate problems compound:

1. {nemoclaw SANDBOX destroy --yes} refuses to delete the retained sandbox, removes nothing, and still exits 0. A refusal reported as success is worse than a plain failure: any script or wrapper that checks the exit code concludes the sandbox was destroyed. {--force} behaves identically.

2. The refusal tells the user to ask an OpenShell administrator to use an identity-bound removal procedure. No such procedure exists in the OpenShell CLI - its only deletion verb is {openshell sandbox delete NAME}, by mutable name, which is exactly the call NemoClaw says it will not make. Meanwhile onboarding refuses to continue until destroy completes, so the two commands point at each other.

3. The blocking state is invisible where a user would look. {nemoclaw list} reports the sandbox as absent while {openshell sandbox list} still reports it present and its containers are still on the host, and a later onboard is still refused because of a retained recovery record the user was never shown.

A workaround does exist and it is the thing the product declined to do: run {openshell sandbox delete NAME} as the ordinary user, then re-run {nemoclaw SANDBOX destroy --yes} to reconcile. Both succeed. So the guidance sends the user to an administrator for something they can do themselves.

Not the same as the two managed llama.cpp lifecycle defects reported earlier. Those were specific to managed llama.cpp state, and in those the destroy either exited 0 while silently succeeding-but-leaking, or the uninstall exited non-zero. Here there is no llama.cpp involved, the agent is plain OpenClaw, destroy explicitly refuses in its own output, and the trigger is simply interrupting the wizard.

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

## Environment

```text
Device: Ubuntu 24.04 virtual machine, no GPU
OS: Ubuntu 24.04 LTS
Architecture: x86_64
Node.js: v22.23.2
npm: 10.9.8
Docker: 29.6.1
OpenShell CLI: 0.0.106
NemoClaw: v0.0.118
OpenClaw: 2026.7.1
```

## Steps to Reproduce

```bash
1. Start the interactive onboarding wizard with an explicit name:

nemoclaw onboard --name SANDBOX --no-gpu

2. Answer the wizard until it reaches the sandbox-creation step and prints
"Creating sandbox ... (this takes a few minutes on first run)".

3. Interrupt it with Ctrl-C while creation is in progress.

4. Try the documented cleanup and record the exit code without piping:

nemoclaw SANDBOX destroy --yes
echo $?
nemoclaw SANDBOX destroy --force
echo $?

5. Compare the three views of the same sandbox:

nemoclaw list
openshell sandbox list
docker ps -a

6. Try to onboard the same name again:

nemoclaw onboard --name SANDBOX --no-gpu

7. Apply the workaround the product declined to perform, as the same ordinary
user, then reconcile:

openshell sandbox delete SANDBOX
nemoclaw SANDBOX destroy --yes
```

## Expected Result

A destroy that removes nothing exits non-zero, so callers can tell the difference between "cleaned up" and "refused".

The remediation the product prints is one the user can actually carry out with the commands they have. If an ordinary {openshell sandbox delete} is sufficient - and it is - the product either performs it or names it, instead of directing the user to an administrator.

The state that blocks onboarding is visible in {nemoclaw list}, or the onboarding refusal names where to look, so the user is not left with a command that reports nothing while another command refuses to proceed because of it.

## Actual Result

```text
Step 4, both variants, verbatim:

Deleting sandbox 'SANDBOX'...
Refusing to automatically delete retained sandbox 'SANDBOX': OpenShell still
reports it present, but its delete command accepts only the mutable sandbox
name. NemoClaw cannot bind that deletion to the retained immutable identity.
No sandbox resources were removed. Ask an OpenShell administrator to resolve
create-attempt label 'LABEL' to the exact sandbox and use an identity-bound
removal procedure. After OpenShell confirms the retained sandbox is absent,
rerun 'nemoclaw SANDBOX destroy --yes' to reconcile its verified Docker
containers and recovery record.

destroy --yes exit 0
destroy --force exit 0

Nothing was removed by either call.

Step 5, the same sandbox seen three ways at the same moment:

nemoclaw list 0 matching entries
openshell sandbox list 1 entry, state Ready
docker ps -a 2 matching containers, one Up and healthy

Step 6, onboarding the same name:

Onboarding cannot use retained sandbox 'SANDBOX' while its identity-bound
recovery record is unresolved.
Run the destroy command for retained sandbox 'SANDBOX' to remove the verified
failed attempt; resume, reuse, recreation, and same-name fresh onboarding
remain disabled until destroy completes.

So destroy says to ask an administrator, and onboard says to run destroy.

Step 7, the workaround, run as the same ordinary user:

openshell sandbox delete SANDBOX
Stopped forward of port PORT for sandbox SANDBOX
Deleted sandbox SANDBOX
exit 0

nemoclaw SANDBOX destroy --yes
Sandbox 'SANDBOX' was already absent from the live gateway.
Sandbox 'SANDBOX' destroyed
exit 0

nemoclaw list 0 openshell sandbox list 0 docker ps -a 0
```

## Logs

```text
The retained record that blocks onboarding, on disk, while {nemoclaw list} shows
nothing:

STATE_DIR/retained-sandbox-recovery.json
schemaVersion 1
unresolved [ { schemaVersion: 1, recordId: ..., sandboxName: ..., ... } ]

A second, related observation on the same host: repeated interrupted attempts
accumulate entries, and a later onboard under a different name reports the older
one rather than clearing it:

Managed bootstrap recovery retained unrelated sandbox 'OTHER'
(RECORD_ID, commit-state-indeterminate).
```