[Linux][Sandbox] uninstall --destroy-user-data removes unrelated containers whose name merely starts with "nemoclaw-"

## Description

Running `nemoclaw uninstall --destroy-user-data` on a shared host removed a pre-existing Docker container that was not created by NemoClaw at all — a container from unrelated manual testing that happened to be named starting with `nemoclaw-`. This is a related but distinct gap from #8496 (closed) about the same uninstall Docker-cleanup logic over-matching resources belonging to the separate OpenClaw project: that report's fix replaced broad substring matching with a more targeted ownership check, but the container-name half of that check still treats any container whose name simply starts with `nemoclaw-` as owned by NemoClaw, regardless of who actually created it or what image it runs. Any user, script, or unrelated project that names a container starting with `nemoclaw-` for any reason is at risk of having that container silently destroyed by someone else's unrelated uninstall run on a shared host.

**Platform scope:** Reproduced on DGX Station GB300; the underlying logic is platform-independent (it operates on Docker container names, not host-specific state), so this likely affects any shared host regardless of platform — not independently verified elsewhere.

**Regression:** Unknown — a related but narrower over-matching issue for a different substring was previously fixed (#8496), but this specific name-prefix gap was not separately tested before or after that fix.

## Environment

```text
Device: DGX Station GB300
OS: Ubuntu 24.04 (DGX OS)
Architecture: aarch64
Node.js: v22.23.2
npm: 10.9.8
Docker: 29.2.1
OpenShell CLI: 0.0.106
NemoClaw: v0.0.114
OpenClaw: N/A (uninstall/reinstall scenario)
```

## Steps to Reproduce

1. On a host with NemoClaw installed, start an unrelated Docker container whose name happens to begin with `nemoclaw-` (simulating a different tool, script, or manual test using that naming convention independently of NemoClaw) — for example:
```bash
docker run -d --name nemoclaw-vllm --rm busybox sleep 3600
```
2. Confirm the container is running and is NOT tracked in any NemoClaw sandbox registry (it was never created via `nemoclaw onboard` or any NemoClaw command).
3. Run:
```bash
curl -fsSL https://raw.githubusercontent.com/NVIDIA/NemoClaw/refs/heads/main/uninstall.sh | bash -s -- --yes --destroy-user-data
```
4. After uninstall completes, check whether the container from step 1 still exists:
```bash
docker ps -a --filter name=nemoclaw-vllm
```

## Expected Result

The unrelated container is left untouched, since NemoClaw never created it. Uninstall should only remove Docker resources it can actually verify it created (for example, via a recorded name from its own sandbox registry, or a label applied at creation time) rather than any container that merely happens to share NemoClaw's naming convention.

## Actual Result

The unrelated `nemoclaw-vllm` container is removed by the uninstall run, purely because its name starts with `nemoclaw-` — the same prefix NemoClaw's own containers use, but not proof that NemoClaw created this specific one. The container and any state inside it (in this case, an actively running manual vLLM test setup from a different user on the same shared host, with several hours of uptime) is lost with no warning that a foreign resource was about to be removed.

## Logs

Not captured — the container was already gone by the time this was investigated; confirmed via `docker ps -a` before and after showing the container present, then absent, immediately following the uninstall run, with no other process on the host that could have removed it.