[Ubuntu 24.04][Onboard] onboarding claims a healthy inference route and exits 0 for an OpenClaw openrouter-api sandbox that status reports unhealthy on /v1/models 404

## Description

Follow-up to #10080, which is closed. The status half of that report is fixed and verified on v0.0.115: `nemoclaw status` no longer calls the route healthy for an OpenClaw sandbox whose `GET /v1/models` returns HTTP 404, and it now names the reason.

The onboarding half still reproduces. On the same sandbox, in the same session, `nemoclaw onboard` finishes with:

```text
[8/8] Policy presets
✓ Deployment verified — gateway, dashboard, and inference route are healthy.
OpenClaw is ready
ONBOARD_EXIT=0
```

while `nemoclaw status` run immediately afterwards reports:

```text
Provider: openrouter-api
Inference: unhealthy (https://inference.local/v1/models)
Inference gateway served a request, but https://inference.local/v1/models returned
HTTP 404, so the selected model was never validated against a model catalog.
```

So the two readiness paths disagree about the same route at the same moment. #10228 states that `launch-readiness/health.ts` was changed to use the same shared exception predicate as status "so the two paths cannot drift"; the onboarding path still asserts the route is healthy.

The practical effect is that a user who onboards this combination is told the deployment is verified and gets exit 0, and only finds out the model was never validated if they separately run `status`. Automation that gates on the onboarding exit code sees success.

Platform scope: Reproduced on Ubuntu 24.04 x86_64 only; other platforms not tested.
Regression: No. This is the remaining half of the originally reported behaviour, not something that previously worked.
OpenShell issue: No.

## Environment

```text
Device: x86_64 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: openshell 0.0.106
NemoClaw: nemoclaw v0.0.115
OpenClaw: v2026.7.1 (bundled with the sandbox image created by this onboarding)
```

## Steps to Reproduce

1. Confirm the OpenRouter key is good, independently of NemoClaw:

```bash
curl -s -o /dev/null -w '%{http_code}\n' \
-H "Authorization: Bearer $OPENROUTER_API_KEY" https://openrouter.ai/api/v1/key
# -> 200
```

2. Onboard an OpenClaw sandbox against `openrouter-api` on its own gateway, and record the exit code:

```bash
OPENROUTER_API_KEY="$OPENROUTER_API_KEY" NEMOCLAW_PROVIDER=openrouter \
NEMOCLAW_GATEWAY_PORT=18901 NEMOCLAW_OPENROUTER_RUNTIME_ADAPTER_PORT=11451 NEMOCLAW_YES=1 \
nemoclaw onboard --agent openclaw --name openclaw-or-edge \
--non-interactive -y --fresh --yes-i-accept-third-party-software
echo "ONBOARD_EXIT=$?"
```

3. Read the route back from status:

```bash
NEMOCLAW_GATEWAY_PORT=18901 nemoclaw openclaw-or-edge status
```

4. Confirm the trigger condition really is present inside that sandbox:

```bash
NEMOCLAW_GATEWAY_PORT=18901 nemoclaw openclaw-or-edge exec --no-tty -- \
sh -lc 'curl -sS -o /dev/null -w "HTTP_STATUS:%{http_code}\n" https://inference.local/v1/models'
# -> HTTP_STATUS:404
```

## Expected Result

Onboarding and status agree. For an agent other than Deep Agents Code on `openrouter-api`, a model-list route that returns HTTP 404 should fail closed in the onboarding path too: onboarding should exit nonzero and should not print that the inference route is healthy.

## Actual Result

Onboarding exits 0 and prints `Deployment verified — gateway, dashboard, and inference route are healthy`, while status on the same sandbox reports the same route unhealthy and explains that the selected model was never validated against a model catalog. The model-list route inside the sandbox returns HTTP 404 throughout.

## Notes

Not a duplicate of #9834, which is the opposite direction: that report is about Deep Agents Code readiness rejecting a sandbox on a 404, and the exception introduced for it is what #10080 found was being applied too widely. This report is only about the onboarding path not having adopted the narrowed predicate that status now uses.

Start with launch-readiness/health.ts and trace the onboarding readiness check alongside the shared exception predicate used by status. Reproduce with the supplied nemoclaw onboard and status commands, then verify that an OpenClaw openrouter-api sandbox returning 404 from /v1/models makes onboarding report the route unhealthy and exit nonzero.

Written by the indexing model from the issue text.