feat(policy): expose active presets, allowed hosts, and approval paths in agent context

[wscurran]

Summary

Agents should understand the active NemoClaw policy environment before attempting network or integration actions. Today, adjacent policy enforcement exists, but the agent can still attempt blocked hosts or unclear workflows because active policy presets, allowed hosts, blocked destinations, and approval paths are not clearly available in the agent context.

Problem

Users can encounter avoidable failures when the agent attempts network access or integration workflows that are predictably blocked by the current policy configuration. When that happens, the agent may not clearly explain whether the failure is caused by policy, missing credentials, unsupported configuration, or a product limitation.

This creates three problems:

• Users see avoidable failures when the agent attempts blocked hosts or integrations.
• The agent cannot clearly explain whether a failure is caused by policy, missing credentials, unsupported configuration, or product limitation.
• Enterprise users do not get a clear approval or remediation path when a needed host, tool, or integration is blocked.

Scope

Add a reliable policy-context surface that agents can use to reason about:

• Active policy presets applied to the sandbox.
• Allowed hosts or service categories, where available.
• Known blocked hosts or restricted paths, where available.
• Approval or remediation paths for blocked access.
• Support boundaries: what NemoClaw can configure, what requires OpenShell/admin action, and what is intentionally unsupported.

Acceptance Criteria

• Agent context includes a concise, redacted summary of active policy presets and relevant network/support boundaries.
• When an attempted host or integration is blocked, the agent can explain the likely policy reason and recommended next step.
• The policy context does not expose secrets, raw tokens, or sensitive internal policy implementation details.
• The behavior is covered by at least one test or scripted validation path.
• User-facing wording distinguishes:
  • blocked by current policy,
  • missing approval/configuration,
  • unsupported capability,
  • unknown failure.