[WSL2][Install] fresh install + onboard takes 25-30 min with no progress feedback; sandbox image and Ollama model download run serially

## Description

On a fresh Windows ARM WSL2 install (no docker image cache, no ollama model cache), getting from `bash install.sh` to a healthy onboarded sandbox takes approximately **25-30 minutes** wall clock. The dominant time is spent inside `nemoclaw onboard`'s `[4/8]` sandbox creation step pulling `ghcr.io/nvidia/nemoclaw/sandbox-base:latest` (~2.41 GB) and then later pulling the Ollama model (`llama3.2:1b`, ~1.3 GB) — and the installer prints almost no progress during these waits, so the user has no idea whether the install is still alive or hung.

The two large pulls (`sandbox-base` and Ollama model) appear to run **serially** rather than in parallel; if they ran concurrently the wall-clock could roughly halve on a network-bound host.

## Environment

```text
Device: Windows ARM reference host (Snapdragon X laptop)
OS: Ubuntu 24.04.4 LTS Noble Numbat inside WSL2
Architecture: aarch64 (Snapdragon X)
Node.js: v22.22.2
npm: 10.9.7
Docker: 29.1.3, build 29.1.3-0ubuntu3~24.04.2
OpenShell CLI: 0.0.39
NemoClaw: v0.1.0 (main HEAD cfa817b)
OpenClaw: 2026.4.24 (cbcfdf6, bundled)
```

## Steps to Reproduce

1. Fresh WSL2 Ubuntu-24.04 (no NemoClaw, no OpenShell, no docker image cache, no ollama model cache).
2. Time the full fresh-install flow:
```bash
time (
bash scripts/install-openshell.sh &&
bash install.sh --yes-i-accept-third-party-software &&
NEMOCLAW_PROVIDER=ollama NEMOCLAW_SANDBOX_GPU=0 \
nemoclaw onboard --fresh --non-interactive --yes \
--yes-i-accept-third-party-software --no-gpu \
--name arm64-test --agent openclaw
)
```
3. Watch the timeline. There are two long quiet stretches inside `nemoclaw onboard`'s `[4/8]` sandbox step (pulling 2.41 GB sandbox-base image, then pulling 1.3 GB ollama model). The installer prints `Creating new sandbox with current image...` once, then offers no progress for 10-15 minutes per pull.

## Expected Result

- Total fresh-install wall-clock should be closer to ~10-15 minutes on a network-bound host, not 25-30 minutes.
- During long pulls (sandbox-base, Ollama model) the installer should print incremental progress: bytes downloaded, current layer, percent complete, or at minimum a ticking heartbeat. Without it the user cannot distinguish "still downloading" from "hung".
- The two large pulls should run in parallel when their dependencies allow it (sandbox-base pull and Ollama model pull have no causal dependency on each other; ollama pull can start in the background as soon as nemoclaw decides on the provider/model).

Concrete asks:

1. Add per-step progress (bytes / percent / ETA) for any pull > 100 MB.
2. Parallelize sandbox-base pull and ollama model pull.
3. Print a one-line summary at install start: "About to download ~3.7 GB across 2 images. ETA ~X min at current bandwidth."

## Actual Result

Observed timeline on a single Windows ARM reference host laptop (residential broadband), measured by polling the `onboard-session.json` `updatedAt` + checking docker / ollama state every 30s:

```text
t=0 `bash install.sh` starts
t=0:30 [1/3] Node.js done (~30 s)
t=2:30 [2/3] NemoClaw CLI done (npm install + tsc, ~2 min on Snapdragon ARM64)
t=2:30 [3/3] Onboarding aborts (OpenShell missing — see NVB#6199869)
t=2:35 bash scripts/install-openshell.sh done (~0.5 min: small tarball)
t=3:00 nemoclaw onboard --resume start
t=4:00 [1/8] preflight done
t=4:30 [2/8] OpenShell gateway healthy
t=6:00 [3/8] inference configured (ollama loopback override + auth proxy)
t=6:00 [4/8] sandbox step begins …
── ~18 minutes of near-silence: pulling sandbox-base (2.41 GB) ──
t=24:00 sandbox container running
t=25:30 [7/8] OpenClaw inside sandbox launched
t=26:00 [8/8] policy presets applied
t=26:00 onboard complete; container reports (unhealthy) until gateway settles
t=27:00 container healthy

Meanwhile, ollama model pull was triggered earlier and took ~5 min (1.3 GB).
It ran sequentially BEFORE the sandbox-base pull, not in parallel.
```

User experience: a long stretch (5-15 minutes) where the only on-screen sign of life is `Creating new sandbox with current image...` with no further update. Hard to tell whether anything is happening.

## Logs

```text
=== docker images that get pulled (sizes from my session) ===
$ docker images | head -10
REPOSITORY TAG SIZE
ghcr.io/nvidia/nemoclaw/sandbox-base latest 2.41 GB ← big one
busybox latest 6.14 MB
curlimages/curl 8.10.1 35.4 MB
node 22-trixie-slim 352 MB
nvidia/cuda 12.6.0-base-ubuntu24.04 375 MB
openshell/sandbox-from 1779349457 ~ same as sandbox-base + overlay

=== ollama models that get pulled ===
$ ollama list
NAME ID SIZE MODIFIED
llama3.2:1b baf6a787fdff 1.3 GB pulled at start of onboard

=== onboard-session.json updatedAt timestamps showing where time goes ===
preflight: started 07:41:22 completed 07:41:26 (~4 s)
gateway: started 07:41:26 completed 07:41:29 (~3 s)
provider_selection: started 07:41:29 completed 07:42:01 (~32 s)
inference: started 07:42:01 completed 07:42:06 (~5 s)
sandbox: started 07:42:06 completed 08:00:37 (~18 min) ← dominant
openclaw: started 08:00:37 completed 08:01:29 (~52 s)
policies: started 08:01:29 completed 08:01:33 (~4 s)
```

## Related

Discovered during ARM64 validation for PR #3925 QA. **Not** PR-introduced — reproduces on `main` HEAD `cfa817b`. Same install slowness presumably affects DGX Spark / Station too on cold-cache fresh installs, though those boxes typically have faster network so the impact is lower than on a residential Windows ARM reference host.

This is the 6th and last bug in the Windows ARM reference host-install-experience series I'm filing today:

- NVB#6198894 (PR-induced regression on Spark+Station ARM64)
- NVB#6199735 (rebuild destroys --no-gpu sandbox)
- NVB#6199755 (openshell-docker-gateway idle shutdown)
- NVB#6199809 (preflight false-positive Snapdragon iGPU as NVIDIA GPU)
- NVB#6199869 (install.sh does not auto-install OpenShell, circular advice)
- this one (perf/UX: install lacks progress feedback + serial-not-parallel downloads)

---
[NVB#6199882](https://nvbugspro.nvidia.com/bug/6199882)