[DGX Spark][Security] Shields auto-relock mid-chat breaks chat silently again, no user-facing warning

> [!WARNING]
> **Regression** — this defect was previously reported and fixed via #5922 (closed as completed 2026-07-07). The same underlying symptom — no user-facing warning when shields auto-relock mid-chat — is reproducing again on v0.0.109, though the specific failure mode is now even less visible (silent success instead of a cryptic error).

## Description

When `shields down --timeout` expires while a chat session is still open, shields auto-relock with no user-visible signal on the chat surface. The next message sent into the still-open chat is accepted and answered normally by the agent, giving no indication that shields re-engaged — the exact silent-failure mode this feature area was previously fixed for.

This is a regression of #5922 ("[DGX Spark][Security] Shields auto-relock mid-chat breaks chat with cryptic `missing scope: operator.write` and no user-facing warning"), fixed via #5951 and closed 2026-07-07 on an earlier NemoClaw version. The same underlying symptom — no user-facing warning when shields auto-relock mid-chat — reproduces again on v0.0.109, though the specific failure mode differs slightly: the previously-fixed bug surfaced a cryptic `missing scope: operator.write` error with no explanation; this time the message is silently accepted and answered with no error and no warning at all, which is an even less visible failure than the original.

Platform scope: Reproduced on DGX Spark (Ubuntu 24.04 aarch64) only; other platforms not tested.

## Environment

```text
Device: DGX Spark (GB10)
OS: Ubuntu 24.04.4 LTS
Architecture: aarch64
Node.js: v22.22.0
npm: 10.9.4
Docker: 29.2.1
OpenShell CLI: 0.0.101
NemoClaw: v0.0.109
OpenClaw: 2026.7.1
```

## Steps to Reproduce

1. Onboard a sandbox with OpenClaw, put it into shields-UP (locked-down) baseline: `nemoclaw {sandbox} shields up`.
2. Run: `nemoclaw {sandbox} shields down --timeout 20s --reason "mid-chat relock test"`.
3. Immediately start an interactive chat: `nemoclaw {sandbox} connect`, then `openclaw tui`; send a message (e.g. "hello") and confirm the agent replies normally while shields are down.
4. Wait more than 20 seconds so the auto-relock timer fires while the chat surface is still open. Confirm via `nemoclaw {sandbox} shields status` that shields are UP again.
5. Send another message into the same still-open chat session (e.g. "are you still there").

## Expected Result

After the timer fires and shields re-engage, the next message attempt in step 5 either surfaces a clear, actionable warning on the chat surface, or fails with a user-visible error explaining that shields re-locked. A silent success that gives no indication shields re-engaged is explicitly the failure mode this area was already fixed for once (#5922).

## Actual Result

`nemoclaw {sandbox} shields status` after the timer fires confirms shields are genuinely UP again:

```text
Shields: UP (lockdown active)
Policy: restrictive (snapshot preserved)
```

The chat message sent afterward is processed completely normally, with no error and no banner:

```text
are you still there

Yes, I am here. How about you?
```

There is no error, no banner, and no indication anywhere on the chat surface that shields auto-relocked. A user watching only the chat would have no way to know their session security posture changed.

## Logs

Not captured (interaction was via the OpenClaw TUI over an SSH session; no separate log file was produced).