[DGX Spark][CLI&UX] scope-upgrade failure still does not name openclaw devices approve on v0.0.114, although the fix is contained in the tag

Follow-up to #9744, which is closed. The condition it described still reproduces on the `v0.0.114` tag, even though the fix for it is contained in that tag.

## Summary

When an operator command run through `nemoclaw {sandbox} exec` fails because the gateway has queued a scope upgrade, the failure output still does not name the commands that clear it. #9853 added a review stanza for exactly this case, and that PR is contained in `v0.0.114`, but the stanza is not emitted.

## Release containment

| PR | Merged | In `v0.0.114` |
|---|---|---|
| #9853 `fix(exec): name the openclaw devices review path on a permission scope upgrade` | 2026-08-21 | yes |

`v0.0.114` was tagged 2026-08-24 05:16 UTC, so the fix is present in the build under test.

## Environment

```text
Device: DGX Spark (NVIDIA GB10)
OS: Ubuntu 24.04 LTS
Architecture: aarch64
OpenShell CLI: 0.0.106
NemoClaw: v0.0.114
```

## Steps to Reproduce

1. On a DGX Spark with a Ready sandbox, run the operator cron registration from the host:

```bash
nemoclaw {sandbox} exec -- openclaw cron add \
--name news-digest --cron "0 8 * * 1-5" --tz America/Los_Angeles \
--agent default --session-key agent:default:news-digest \
--message "Run my daily news briefing now." --no-deliver --token ""
```

2. Capture stdout and stderr separately and read both in full.

## Actual Result

`stdout` is empty. `stderr` is 992 bytes and contains, in full:

```text
Active gateway set to 'nemoclaw'
Config warnings:
- plugins.entries.tavily: plugin not installed: tavily ...
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: {id})
GatewayTransportError: gateway closed (1008): pairing required: device is asking for more scopes
than currently approved (requestId: {id})
Gateway target: ws://127.0.0.1:{port}
Source: local loopback
Config: /sandbox/.openclaw/openclaw.json
Bind: loopback
```

Occurrences in the combined output:

```text
"waiting for approval" : 0
"devices list" : 0
"devices approve" : 0
```

The review stanza `#9853` adds does not appear.

## Expected Result

The failure names the commands that clear it, as `#9853` describes:

```text
nemoclaw: a device scope upgrade is waiting for approval inside sandbox '{sandbox}'.
The OpenClaw gateway refused the command until the requested scopes are approved.
Review pending requests: nemoclaw {sandbox} exec -- openclaw devices list
Approve the one you recognize, after checking its device and requested scopes:
nemoclaw {sandbox} exec -- openclaw devices approve
```

## What was ruled out

The obvious explanations were tested rather than assumed.

**1. Sandbox age.** Reproduced on two sandboxes: one carried over from `v0.0.113` and upgraded in place, and one created fresh on `v0.0.114`. Identical result on both.

**2. No pending request to find.** A pending request was present at the moment of the failure, with the same `requestId` that the error prints:

```text
$ nemoclaw {sandbox} exec --no-tty -- openclaw devices list
Pending (1)
Request Device Requested Age Status
{id} {device} roles: operator; 3m ago scope upgrade, repair
scopes: operator.admin
```

**3. The probe failing.** `#9853` appends the stanza only after probing with `openclaw devices list --json`. That command works and returns the pending entry:

```text
$ nemoclaw {sandbox} exec --no-tty -- openclaw devices list --json
exit 0, valid JSON
{
"pending": [
{
"requestId": "{id}",
"deviceId": "{device}",
"clientId": "cli",
"role": "operator",
"scopes": ["operator.admin"],
"isRepair": true,
"ts": 1787554085605
}
],
"paired": [ ... ]
}
```

So the data the hint depends on is present and retrievable at the time it should be emitted.

## The contrast in the original report still holds

On the same build and in the same session, the network-policy denial path still prints its breadcrumbs:

```text
See the denied flow: nemoclaw {sandbox} logs --tail 50
Allow the host: nemoclaw {sandbox} policy add {preset}
```

The scope-approval path prints none.

Start by tracing the nemoclaw {sandbox} exec scope-upgrade failure and compare its output path with the review stanza from PR #9853. Reproduce the command while capturing stdout and stderr, then verify that a successful openclaw devices list --json probe causes the pending-request review and approval commands to appear.

Written by the indexing model from the issue text.