Feature: Policy Profiles for Sandbox, Network, Tool, and Mode Constraints

## Summary

Add named policy profiles that bundle sandbox, network, tool, permission, and mode constraints so users can consistently run Forge under repeatable operating postures such as offline, audit-only, CI-safe, high-trust local, or strict review.

## Problem / Opportunity

Forge already has modes, permission flags, command risk classification, filesystem sandboxing, provider routing, and non-interactive behavior. These controls are currently spread across commands and config. Users need a higher-level way to define and reuse policies like:

- No network, local models only, read-only tools.
- Allow file edits but deny shell execution.
- Permit only specific MCP namespaces.
- Require prompts for all medium/high-risk actions.
- Run validation but never mutate files.
- CI-safe behavior with deterministic denial instead of interactive prompts.

Named policy profiles would make Forge more predictable for teams, scripts, and sensitive repositories.

## Proposed Feature

Introduce policy profiles with CLI, config, and dashboard support:

- Profile schema covering mode defaults, provider restrictions, allowed tool classes, max risk, allowed roots, network/web/MCP access, shell policy, validation requirements, and non-interactive behavior.
- `forge policy list/show/create/edit/validate` commands.
- `forge run --policy ` and dashboard task policy selection.
- Built-in profiles such as `offline-readonly`, `ci-safe`, `strict-local`, and `interactive-default`.
- Policy evaluation reports that explain why an action was allowed, warned, or denied.
- Documentation showing how policy profiles relate to modes and permission flags.

## Scope

Expected implementation areas:

- `src/core/mode-policy.ts` for integration between existing modes and policy overlays.
- `src/permissions/manager.ts` and `src/permissions/risk.ts` for policy decisions.
- `src/sandbox/fs.ts` and `src/sandbox/shell.ts` for filesystem and command constraints.
- `src/models/router.ts` for provider restrictions such as local-only.
- `src/config/schema.ts` and `src/config/loader.ts` for profile persistence.
- CLI command additions under `src/cli/commands/`.
- Dashboard configuration/task-runner support.
- Tests covering policy parsing, precedence, and enforcement.

## Acceptance Criteria

- [ ] Users can define named policy profiles in config and select one per run.
- [ ] Built-in profiles provide sensible defaults for offline-readonly, CI-safe, strict-local, and interactive-default workflows.
- [ ] Policy evaluation occurs before tool execution and still routes through `requestPermission` where appropriate.
- [ ] Provider restrictions can enforce local-only or specific provider allowlists.
- [ ] Tool restrictions can deny by tool name, side effect, risk, or namespace.
- [ ] CLI and dashboard expose the active policy for a task.
- [ ] Denied actions include a clear policy reason without leaking sensitive command/path data.
- [ ] Tests cover interactions between policies, modes, blanket flags, non-interactive mode, and cached grants.

## Non-Goals

- Replacing modes entirely.
- Implementing organization-wide remote policy distribution in the first version.
- Supporting arbitrary JavaScript policy plugins.
- Weakening critical-risk hard blocks.

## Dependencies / Risks

- Precedence between mode, flags, profile, project config, and global config must be explicit.
- Existing CLI flags should remain backwards compatible.
- Policy checks must not create alternate paths around `requestPermission`.
- Dashboard policy selection must be serialized into task records for replay/audit.

## Open Questions

- Should `--policy` override mode settings, or should mode caps always be the upper bound?
- Should project-local policy profiles be allowed to relax global profiles?
- Should policy violations be terminal failures or resumable blocked states?
- Should policy profiles be exportable as shareable files?