[Ubuntu 26.04][CLI&UX] nemoclaw status shows another sandbox's model on that sandbox's Inference (configured) line

## Description

nemoclaw status labels each sandbox's route line "Inference (configured)", but for a
sandbox that is not the one whose route the gateway currently serves, that line shows a
different sandbox's provider and model instead of the values the sandbox itself was
onboarded with. An ordinary stop/start of one sandbox silently changes what status
reports as "configured" for a different sandbox.

The product still holds the correct per-sandbox value and prints it one line above as
"(onboarded: {model})", so the two lines disagree with each other in the same output
block. nemoclaw status --json shows the same overwritten value, so this is not only a
display issue.

One shared inference route per gateway is expected behaviour and is not what this bug is
about. The defect is that a line labelled "configured" renders the shared live route
rather than the sandbox's own recorded configuration.

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

## Environment

```text
Device: Ubuntu 26.04 host, x86_64
OS: Ubuntu 26.04 LTS
Architecture: x86_64
Node.js: v22.23.2
npm: Not on PATH (installer-managed Node.js)
Docker: Docker version 29.6.1, build 8900f1d
OpenShell CLI: openshell 0.0.106
NemoClaw: nemoclaw v0.0.121
OpenClaw: 2026.7.1
```

## Steps to Reproduce

```bash
1. Onboard a first sandbox with one local Ollama model:

NEMOCLAW_PROVIDER=ollama NEMOCLAW_MODEL=llama3.2:1b nemoclaw onboard \
--name configured-route-a --no-gpu --non-interactive --yes

2. Onboard a second sandbox with a DIFFERENT model on the same gateway:

NEMOCLAW_PROVIDER=ollama NEMOCLAW_MODEL=qwen2.5:0.5b nemoclaw onboard \
--name configured-route-b --no-gpu --non-interactive --yes

3. Stop and start the FIRST sandbox:

nemoclaw configured-route-a stop
nemoclaw configured-route-a start

4. Run:

nemoclaw status

5. Run:

nemoclaw status --json
```

## Expected Result

Each sandbox's "Inference (configured):" line shows the provider and model that sandbox
itself was configured with. Stopping and starting one sandbox does not change what is
displayed as "configured" for a different sandbox.

## Actual Result

Step 4, verbatim:

Global status (registered sandboxes and host services):
Sandboxes:
configured-route-a (llama3.2:1b) :18789
Inference (configured): ollama-local / llama3.2:1b
SSH sessions: none
configured-route-b * (llama3.2:1b) :18790
(onboarded: qwen2.5:0.5b)
Inference (configured): ollama-local / llama3.2:1b
SSH sessions: none

configured-route-b was onboarded with qwen2.5:0.5b, but its "Inference (configured)"
line shows llama3.2:1b, which belongs to configured-route-a. The "(onboarded:
qwen2.5:0.5b)" line directly above shows the product still knows the correct value.

Step 5, relevant excerpt from nemoclaw status --json at the same moment:

"sandboxes": [
{ "name": "configured-route-a", "model": "llama3.2:1b", "provider": "ollama-local" },
{ "name": "configured-route-b", "model": "llama3.2:1b", "provider": "ollama-local" }
]

configured-route-b's JSON "model" field is also llama3.2:1b.

Step 3 is the trigger. Starting the first sandbox prints:

Warning: gateway inference route (ollama-local/qwen2.5:0.5b) differs from the recorded
route for sandbox 'configured-route-a' (ollama-local/llama3.2:1b). Aligning the gateway
to ollama-local/llama3.2:1b.

## Logs

```text
Not captured beyond the terminal output quoted in Actual Result.
```

Start with the implementation of `nemoclaw status` and its `--json` output, then trace how each sandbox's recorded onboarding route is read versus the shared gateway route. Reproduce the two-sandbox sequence from the issue and verify that both text and JSON report each sandbox's own configured provider and model after stopping and starting the first sandbox.

Written by the indexing model from the issue text.