Invocation-owned permission maximum for embedded and standalone runtimes #56351

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

For embedded applications and explicitly owned standalone invocations, add an opt-in, host-owned permission maximum. A host could keep one stable tool/permission budget while agents and sessions retain their ordinary rules. This is a new restriction within a trusted runtime, not a change to the default trust model.

Proposed API (not installed-version syntax):

• Typed ServerOptions.permissions.maximum, separate from authored config and session fields; strict, nonempty existing-rule arrays starting with deny-all, allowing only allow/deny.
• New OPENCODE_PERMISSION_MAXIMUM transports strict JSON to explicit CLI owners. Only unset disables it; malformed input and unsupported managed/remote ownership fail before I/O. No new CLI flags or implicit standalone conversion.
• Copy/freeze once per owning application graph, shared by normal, lazy/private and child-session graphs, independent of mutable authored/session/saved rules. A maximum can only reduce permissions: its ALLOW never lifts native or organization DENY. Unset preserves existing behavior and matching semantics.
• Enforce both permission assertions and actual registry/executor availability, including execute. Empty-resource requests require an action-wide allowance; registry-only entrypoints reject resource-scoped rules that cannot be enforced there.

This is not an OS sandbox, path canonicalizer, configuration isolation or provider-I/O filter. Trusted plugin/host I/O and composition remain trusted. No installation, release, adoption or native compatibility is claimed.

Related: #40805 proposes a broader authored-rule/inheritance redesign; this narrower option leaves that language and rule ordering unchanged. This is also separate from content-only configuration authority.

A reviewed local prototype is available through a permitted review channel; no implementation PR is being opened. Recorded source-only validation: 74 focused tests pass, six unrelated cases remain pending, and four complete package-owner incremental typechecks pass. These are local source results, not CI or native-runtime qualification; the pending cases are not claimed fixed.

Before an implementation contribution, would this ownership boundary and default-unset contract fit OpenCode? In particular, should the maximum live on ServerOptions.permissions, should unsupported CLI ownership reject rather than coerce, and is a separate permission-and-registry graph cap the desired trust/API boundary?