[DGX Spark][Agent&Skills] OpenClaw agent does not use its Brave-backed web_search tool for a web-search request — falls back to URL fetch and reports the network as blocked

## Description

With Brave Search fully enabled, the OpenClaw agent does not use its own
Brave-backed `web_search` tool when asked to search the web. It reaches for a generic
URL fetch instead, which the Balanced policy correctly denies at the egress proxy
with 403, and then reports to the user that outbound web requests are blocked - on a
sandbox where web search is working.

Everything Brave needs is verifiably in place on the test sandbox:
- the `brave` preset shows as applied in policy-list
- the live policy contains `- host: api.search.brave.com`
- BRAVE_API_KEY is set inside the sandbox
- GET https://api.search.brave.com/res/v1/web/search?q=nvidia from INSIDE the
sandbox returns HTTP 200
- `openclaw plugins list` inside the sandbox shows Brave / brave / enabled / 2026.7.1
- the agent itself, when asked to list its tools, reports
"web_search (OpenClaw core) - Brave-based web search"

The tool works when the agent is pushed to it explicitly. What fails is the agent's
own choice of tool for an ordinary web-search request.

Control performed: the host reaches api.search.brave.com with the same key (HTTP 200),
and so does the sandbox, so this is not a corporate egress problem and not a policy gap.

Related, not duplicates:
- GitHub #2433 (Hermes agent does not invoke the Brave web_search tool, falls back to
browser_navigate and hallucinates, fixed 2026-05-04) - same class of failure, but
that was the Hermes agent falling back to browser_navigate. This is OpenClaw
falling back to a URL fetch. Worth checking whether the #2433 fix needs the same
treatment on the OpenClaw side.
- GitHub #3948 (agent claims no web access and the Brave key is not usable inside the
sandbox, fixed 2026-07-10) - there the key genuinely was not usable. Here the key
and the egress are both verified working from inside the sandbox.

Impact: the published DGX Spark playbook's Brave verification step tells the reader to
"ask the agent for something that needs live web search". Following it makes a correct
setup look broken and sends the reader into a troubleshooting path with nothing to fix.
The documentation side is tracked separately as a playbook documentation issue; the
doc can only work around this by telling every reader to say "use your search tool,
not a URL fetch".

Platform scope: Reproduced on DGX Spark (Ubuntu 24.04 aarch64) only; other platforms not tested.
Regression: Unknown for the OpenClaw agent - earlier versions not tested for this behaviour. The equivalent Hermes behaviour was fixed under GitHub #2433.
OpenShell issue: No

## Environment

```text
Device: DGX Spark (GB10)
OS: Ubuntu 24.04.3 LTS
Architecture: aarch64
Node.js: v22.22.1
npm: 10.9.4
Docker: 28.3.3
OpenShell CLI: 0.0.101
NemoClaw: v0.0.111
OpenClaw: 2026.7.1
```

## Steps to Reproduce

```bash
1. On a DGX Spark with a Ready sandbox, enable Brave:
(with your Brave Search API key exported as BRAVE_API_KEY in the environment)
nemoclaw onboard --name my-assistant --recreate-sandbox --non-interactive
2. Confirm Brave is genuinely wired in:
nemoclaw my-assistant policy-list | grep -i brave
nemoclaw my-assistant exec -- sh -c 'openclaw plugins list | grep -i brave'
nemoclaw my-assistant exec -- sh -c 'curl -s -o /dev/null -w "%{http_code}\n" -H "X-Subscription-Token: {the key the sandbox already holds}" "https://api.search.brave.com/res/v1/web/search?q=nvidia"'
3. Open the agent:
nemoclaw my-assistant connect
openclaw tui
4. Ask three ways, in this order:
a. "Search the web and tell me the current NVIDIA stock price headline today."
b. "Use Brave web search to find today's top NVIDIA news headline."
c. "Use the Brave search plugin's search tool (not a URL fetch) to search for
'NVIDIA DGX Spark' and show me the first result title."
```

## Expected Result

A plain web-search request (a) makes the agent use its web_search tool and return a
live result. At minimum, naming Brave explicitly (b) should do so.

## Actual Result

```text
(a) The agent tries generic URL fetches - Yahoo Finance, Google Finance, CNBC,
Wikipedia - all denied 403, then reports:
"I'm encountering an outbound network restriction. The sandbox firewall/proxy
is returning 403 CONNECT tunnel failed for all external URLs I've attempted
... outbound network is deny-by-default in this sandbox environment."

(b) Naming Brave explicitly still fails:
"All outbound network requests are still being blocked by the sandbox policy -
the proxy returns 403 CONNECT tunnel failed for Brave Search, just like every
other site I tried earlier."

(c) Only when told not to fetch URLs does it use the tool, and it works:
"First result from the Brave web search:
'Personal AI Supercomputer Powered by Blackwell | NVIDIA DGX Spark'
From nvidia.com (published 2 days ago)."
```

## Logs

```text
Agent's own tool inventory, same session, asked between (b) and (c):

"web_search (OpenClaw core)
- Brave-based web search
- Supports: query, result count (1-10), country, language, freshness filters
(day/week/month/year), date range, search language, UI locale, domain filter"

Sandbox-side proof that the route and key are fine, taken in the same state:

Brave API key present in the sandbox environment: yes
api.search.brave.com: 200

openclaw plugins list:
Brave | brave | openclaw | enabled | $OPENCLAW_HOME/.openclaw/npm/projects/openclaw-brave- | 2026.7.1

openshell policy get my-assistant --full | grep -i brave:
brave:
name: brave
- host: api.search.brave.com
```

Reproduce the three prompts with `nemoclaw my-assistant connect`, `openclaw tui`, and the listed Brave checks, then trace the OpenClaw tool-selection path for ordinary and explicitly requested searches. Done means both ordinary and Brave-named requests invoke `web_search` and return results instead of attempting URL fetches, with regression coverage for the demonstrated behavior.

Written by the indexing model from the issue text.