[Ubuntu 24.04][Sandbox] channels add teams port conflict destroys sandbox instead of failing cleanly

A host port already in use by an unrelated process causes `channels add teams` + rebuild to destroy the sandbox entirely instead of failing cleanly and leaving it intact.

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

## Environment

```text
Device: x86_64 Linux server
OS: Ubuntu 24.04.4 LTS
Architecture: x86_64
Node.js: v22.23.2
npm: 10.9.8
Docker: 29.5.2
OpenShell CLI: 0.0.106
NemoClaw: v0.0.114
OpenClaw: 2026.7.1
```

## Steps to Reproduce

1. Onboard a sandbox with no messaging channel (any provider/model):
```bash
nemoclaw onboard --name {sandbox} --agent openclaw
```
2. Occupy host port 3978 with an unrelated process:
```bash
nohup nc -l 3978 &
```
3. Export valid `MSTEAMS_APP_ID` / `MSTEAMS_APP_PASSWORD` / `MSTEAMS_TENANT_ID` and run:
```bash
nemoclaw {sandbox} channels add teams
```
4. Answer `y` to "Rebuild {sandbox} now to apply?"

## Expected Result

Fails fast with a message naming the port and PID already occupying it, hints to free the port or set `MSTEAMS_PORT`, adds no partial channel, and leaves the sandbox intact.

## Actual Result

The rebuild proceeds, destroys the old sandbox, then fails to recreate it because the Teams webhook port is unavailable — leaving no sandbox at all instead of a clean abort.

```text
Rebuild sandbox '{sandbox}'
Docker / CDI GPU / bridge containers / DNS / runtime / openshell checks pass
Backing up sandbox state...
State backed up (11 directories, 1 files)
Deleting old sandbox...
[rebuild proceeds: new container created, GPU proof passes]
Microsoft Teams webhook forward on port 3978 did not start: port 3978 is already in use before forward start
Reconnect after resolving the issue: nemoclaw {sandbox} connect
Stopped forward of port 18793 for sandbox {sandbox}
No active forward found for port 3978 on sandbox {sandbox}
Deleted sandbox {sandbox}

Could not allocate a dashboard port for '{sandbox}'.
Failed to start Microsoft Teams webhook forward on port 3978. Free the port and re-run onboard, or choose a different messaging channel port.
The orphaned sandbox has been removed. Resolve the error above before retrying.

Recreate failed after sandbox was destroyed.
Backup is preserved at: {home}/.nemoclaw/rebuild-backups/{sandbox}/{timestamp}

To recover manually:
1. Fix the issue above (missing credential, Docker problem, etc.)
2. Run: nemoclaw onboard --resume --name {sandbox} --tool-disclosure progressive
3. Then restore your workspace state: nemoclaw {sandbox} snapshot restore "{timestamp}"

Onboarding did not finish. Resume from the step that failed with:
nemoclaw onboard --resume
```

Verified the sandbox was actually gone via `nemoclaw list` (no longer listed) and `docker ps -a` (no container).

A cascading symptom observed in the same session: the destroyed sandbox's registry entry became stale rather than fully cleared — `nemoclaw {destroyed-sandbox} channels status` still reported Teams as registered and applied for a sandbox already absent from `nemoclaw list` and `docker ps -a`. That stale entry then blocked a separate, still-live sandbox sharing the same Teams credential from running `channels start teams` + rebuild, rejecting it with a credential-conflict error naming the already-destroyed sandbox. Running `nemoclaw {destroyed-sandbox} channels remove teams` against the phantom sandbox name released the credential lock (with its own secondary warning about failing to un-apply the policy preset) — this only unblocks the second sandbox, it does not address the root destroy-on-conflict behavior.

## Related Bugs

#5954 — "channels start rebuild destroys sandbox before messaging credential conflict check, leaving sandbox permanently lost." Fixed for the case where two sandboxes share the same messaging credential (a dedicated preflight guard now checks that before any destructive step). This report reproduces the same non-atomicity contract failing for a different, still-uncovered trigger: a plain OS-level port already in use by an unrelated process, with no credential sharing involved.

## Logs

Not captured beyond the terminal output already shown above.