feat(policy): add managed maximum permission modes

[zredlined]

Summary

Implement the core workflow for gateway-managed maximum policies from #2109. This draft currently
supports filesystem, raw L4, and enforced REST containment with immutable ask or auto permission
modes, provider composition, and live-state revalidation.

It also replaces the legacy empty-finding proposal auto-approval gate so reviewers can evaluate one
security decision surface before GraphQL, remote MCP, and multi-policy agent/subagent composition
add more policy-language and API complexity.

This remains a draft. Feedback on the core workflow is intended to shape those remaining
expansions, all of which remain in scope for #2109 and this work.

The current complete diff is a net reduction: 4,432 additions and 4,732 deletions across 83 files.

Related Issue

Part of #2109

Current Slice

• Add one versioned gateway-managed maximum using existing policy YAML plus allowed/default modes
  and review.required annotations.
• Prove fully composed sandbox and provider policy containment for filesystem, raw L4, and enforced
  REST authority.
• Enforce the same live-state-revalidated admission operation at sandbox creation, provider
  changes, direct policy updates, and proposal application.
• Add immutable ask and auto sandbox permission modes. Managed auto applies only the requested
  delta inside the auto-eligible maximum view.
• Reject explicit denies, outside-maximum authority, unsupported policy shapes, providers without
  resolvable profiles, and always-blocked network targets.
• Keep credentialed raw-L4 detection as an advisory that cannot authorize or veto admission.
• Remove proposal_approval_mode, sandbox create --approval-mode, the empty-prover-delta approval
  path, and their settings/audit/test surface.
• Remove openshell policy prove and the legacy risk-query modules, registries, accepted-risk
  files, testdata, dependencies, and CLI build wiring.
• Update the TUI, embedded agent skill, docs, examples, man page, release builds, and audit copy for
  the single admission model.
• Limit the initial proof-to-commit boundary to single-replica SQLite storage.

Compatibility

• Unmanaged proposal automation is intentionally removed. Unmanaged proposals remain pending.
• Hands-off workflows configure an explicit managed maximum and choose managed auto.
• Stale persisted proposal_approval_mode values are inert.
• GraphQL, remote MCP, and other not-yet-modeled managed authority fail closed until their
  in-scope containment expansions are implemented.

Review Guide

The commits are semantic slices within this one draft PR:

1. Managed maximum containment and policy parsing.
2. Managed admission across authority-changing paths.
3. Docker-backed golden flow.
4. Single proposal admission gate and credentialed raw-L4 advisory.
5. Legacy risk-query prover and CLI removal.
6. Replacement documentation and examples.

Review the current final contract once; the commit boundaries are navigation aids rather than
intermediate states that need separate approval.

Testing

• Affected CLI, core, OCSF, prover, and TUI suites: 799 tests passed.
• Complete openshell-server suite with test-support: 933 tests passed.
• Affected-package Clippy passes with warnings denied.
• Server Clippy passes with the unrelated existing Podman unused import allowed.
• Workspace cargo check, Rust formatting, Markdown lint, license headers, and shell syntax.
• Docker managed-maximum golden flow passed on commit 0cd2922.
• Rerun the Docker golden flow after the cleanup commits.
• mise run pre-commit remains blocked by unrelated baseline failures: the unused Podman Path
  import and Helm chart dependency metadata for postgresql.

Reviewer smoke test

RUST_LOG=info CARGO_BUILD_JOBS=8 +      OPENSHELL_E2E_DOCKER_TEST=managed_maximum +      mise run e2e:docker

The test prints maximum setup, managed-mode UX, automatic GET approval, reviewed POST approval,
DELETE rejection, live reload, audit visibility, and cleanup.

Remaining In Scope

• Add GraphQL endpoint, operation, and root-field containment behind the same admission boundary.
• Add remote MCP endpoint and tool containment behind the same admission boundary.
• Add multiple policy inputs for parent agents and subagents while retaining the organization
  maximum as the outer boundary; use core-workflow feedback to finalize the composition API.
• Add candidate/delta hashes and non-secret provider identity to admission audit evidence.
• Constrain or safely encode policy metadata used in formatted audit messages.
• Extend fixtures, examples, and golden coverage for GraphQL, MCP, and nested agent policies.
• Rerun the managed-maximum Docker golden flow after each expansion and on the final branch.

Checklist

• Follows Conventional Commits.
• Commits are signed off for DCO.
• Current user-facing and architecture documentation matches implemented behavior.
• Legacy enforcement and documentation surfaces were removed instead of retained beside the
  new contract.
• GraphQL, remote MCP, and multi-policy expansion are complete.
• Final project gates pass or unrelated baseline failures are explicitly resolved.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[github-actions]

🌿 Preview your docs: https://nvidia-preview-pr-2168.docs.buildwithfern.com/openshell

[github-actions]

This pull request has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity.

[lbelyaev]

Reviewing this as someone who runs the composed-maximum model against enterprise requirements — the core contract is the right shape, and checking the absolute composed candidate against the hard ceiling (check_within_maximum, not the delta) is the part that matters most and it's correct. One design question on the auto path.

The auto-vs-review decision splits by source: SandboxCreate evaluates the absolute candidate against the auto-eligible maximum (~line 215), but the incremental path evaluates requested_delta (~line 246). So the hard ceiling is absolute — nothing gets past it — while the line between auto and review is delta-scoped on increments. A run of individually auto-eligible deltas can add up to authority that, requested as one candidate, would have crossed into review-required, with each step auto-applying because each delta alone is inside the auto-eligible view. That matters because the review-required set is usually where the sensitive "a human signs off each time" grants live — exactly the authority you'd least want built up past silently. Whether it's acceptable depends on intent: if auto-eligible means "small steps here are fine even if they add up," the delta check is right; if the review-required set is meant to gate the composed result, the incremental path would want to check the absolute candidate the way SandboxCreate already does. Worth stating which the design intends.