…NVIDIA#2180)

After a fresh `nemoclaw onboard` with Balanced tier defaults, where the
user explicitly skipped messaging channels in step [5/8] and did not
tick Discord in step [8/8], `nemoclaw <name> policy-list` reports:

    ● discord — Discord API, gateway, and CDN access
      (active on gateway, missing from local state)

The sandbox can reach `discord.com`, `gateway.discord.gg`, and
`cdn.discordapp.com` without the user having opted in — the base
sandbox policy's own header says "deny by default, allow only what's
needed for core functionality," which messaging to third-party IM
platforms is not. Same story for `api.telegram.org`.

This is a regression, not a new bug:

- NVIDIA#1705 (2026-04-09, 77051cc) removed pre-allowed `telegram` and
  `discord` from `nemoclaw-blueprint/policies/openclaw-sandbox.yaml`
  for exactly this reason.
- NVIDIA#1700 (2026-04-14, 855924f), an unrelated npm_registry PR, was
  rebased on a branch that predated NVIDIA#1705 and re-added both entries
  during conflict resolution. The CodeRabbit release notes on NVIDIA#1700
  even called this out as "Added network policy entries to enable
  controlled Telegram and Discord messaging access" — it landed along
  with the legitimate npm_registry tightening and has been in the
  baseline since.

Once a key like `discord` exists in the gateway's loaded policy,
`policies.getGatewayPresets()` detects the Discord preset as active
(it matches on key presence), and `policy-list` then renders the
misleading "active on gateway, missing from local state" line.

- Re-remove `telegram` and `discord` entries from
  `nemoclaw-blueprint/policies/openclaw-sandbox.yaml`. Messaging
  endpoints are only reachable if the user selects the matching
  channel in step [5/8] and the corresponding preset is applied on
  top of the baseline in step [8/8]. Leave a comment block at the
  removed location referencing NVIDIA#1705, NVIDIA#2180, and the preset path so
  the next merge-conflict resolution does not casually re-add them.
- Add three regression tests in `test/validate-blueprint.test.ts`
  mirroring the existing `NVIDIA#1583` GitHub pattern:
  - `regression NVIDIA#2180: base policy does not silently grant Telegram access`
  - `regression NVIDIA#2180: base policy does not silently grant Discord access`
  - `regression NVIDIA#2180: base policy does not silently grant Slack access`
    (guard against the same merge pattern re-adding Slack even though
    it was never in the baseline historically)
  Each asserts both the key absence in `network_policies` and the
  absence of any host-matching endpoint anywhere in the base policy,
  so a rename can't smuggle the grant back in.

- `npx vitest run test/validate-blueprint.test.ts test/policies.test.ts`
  — 124 tests pass including the 3 new regressions.
- `npx vitest run test/validate-configs-dangerous-hosts.test.ts test/onboard.test.ts`
  — 160 tests pass, no onboard flow regressions.

Touches only the base policy YAML and the blueprint validator. Does
not modify any preset (presets/telegram.yaml, presets/discord.yaml,
presets/slack.yaml) — users who enabled messaging via onboard still
get the same preset applied on top of baseline and retain the same
endpoint access. The permissive variant
(openclaw-sandbox-permissive.yaml), used for
`--dangerously-skip-permissions`, is intentionally unchanged.

Fixes NVIDIA#2180.

Signed-off-by: latenighthackathon <latenighthackathon@users.noreply.github.com>