[DGX Spark][Sandbox] rebuild drops serving profile provenance from the sandbox registry

> [!NOTE]
> **Re-verified reopening of #11417** - closed via #11686 (merge commit confirmed an ancestor of v0.0.124 and v0.0.125). Re-verification today still fails to show the provenance lines after rebuild, but with a different observed root cause than originally reported: the "Serving profile:" / "Serving recipe:" / "Catalog digest:" lines are absent from `status` **before** the rebuild as well as after. Inspecting the sandbox registry directly (`sandboxes.json`) confirms `servingProfileProvenance` is entirely absent from the record from the moment onboarding completes - it is never populated, not dropped during rebuild. #11686 fixes rebuild's handling of an already-populated provenance value; it does not address onboarding never populating that value in the first place for this profile/path. See the QA verify comment on the linked NVBug for the full repro transcript.

## Description

A sandbox onboarded with an explicit managed vLLM serving profile reports its serving profile, serving recipe and catalog digest in `nemoclaw status`. After a successful rebuild those three lines are gone from status, permanently. Provider, model, phase and inference health remain correct and the sandbox works, so nothing visibly breaks - the provenance information is simply no longer recorded and cannot be recovered from the CLI.

The rebuild otherwise preserves the serving configuration: the rebuilt sandbox serves the same profile and model, runs in resume mode without re-selecting a model, and does not re-download the model. So the provenance loss is inconsistent with the rest of the rebuild's behaviour.

Consequence: after any rebuild there is no supported way to confirm from the CLI which serving profile a sandbox is actually running.

Platform scope: Reproduced on DGX Spark GB10 aarch64 only; other platforms not tested.
Regression: Unknown - earlier versions not tested for this path.
OpenShell issue: No

## Environment

```text
Device: DGX Spark GB10
OS: Ubuntu 24.04.4 LTS
Architecture: aarch64
Node.js: v22.23.2
npm: 10.9.8
Docker: Docker version 29.2.1, build a5c7197
OpenShell CLI: openshell 0.0.106
NemoClaw: nemoclaw v0.0.121
OpenClaw: 2026.7.1
```

## Steps to Reproduce

1. Onboard a sandbox with an explicit managed vLLM serving profile:

```bash
nemoclaw onboard --name muse-vllm-life \
--profile vllm.dgx-spark-gb10.single.muse-glimmer-30b-nvfp4-w4a4 \
--fresh --non-interactive --yes --yes-i-accept-third-party-software
```

2. Record the profile-related lines:

```bash
nemoclaw muse-vllm-life status
```

3. Rebuild the sandbox and confirm it exits 0:

```bash
nemoclaw muse-vllm-life rebuild --yes
```

4. Compare status again:

```bash
nemoclaw muse-vllm-life status
```

## Expected Result

A successful rebuild preserves the sandbox's serving configuration, so status keeps reporting the same serving profile, serving recipe and catalog digest afterwards.

## Actual Result

Step 2, before rebuild, status includes lines of the form:

```text
Serving profile: vllm.dgx-spark-gb10.single.muse-glimmer-30b-nvfp4-w4a4
Serving recipe: {recipe id}
Catalog digest: {digest}
```

Step 3 succeeds:

```text
Sandbox 'muse-vllm-life' rebuild completed
Now running: OpenClaw v2026.7.1

exit code 0
```

Step 4, after rebuild, those three lines are no longer printed at all. Status is not reporting an error - the fields are simply absent.

Everything else about the rebuild is correct in the same run: provider and model are still vllm-local / muse-glimmer before and after, the rebuild ran in resume mode without asking to select a model, and the 23.7 GiB model was not re-downloaded (about 58 seconds to re-create versus roughly 7 minutes for the original onboard). An agent request returned its expected marker both before and after the rebuild.

**Re-verification update:** on v0.0.124/v0.0.125, the provenance lines are absent even before any rebuild - the field is never populated at onboard time for this profile/path, not lost during rebuild. See the note at the top of this issue.

## Logs

Not captured beyond the terminal output quoted in Actual Result.