execpolicy prompt rules should support forcing user approval when auto-review is enabled

What feature would you like to see?

Add a way for execpolicy prefix_rule(..., decision = "prompt") rules to require human/user approval even when the current thread is otherwise configured to route approval prompts through Auto-review / Guardian.

Today approval routing is effectively global for shell/exec-policy prompts:

• approvals_reviewer = "user" sends approval prompts to the user.
• approvals_reviewer = "auto_review" sends eligible approval prompts to Auto-review / Guardian.
• prefix_rule(..., decision = "prompt") only means "this command needs approval"; it does not let the rule choose who reviews it.

That makes it hard to use Auto-review for the normal case while still requiring explicit human confirmation for especially sensitive command families.

Proposed behavior

Support an optional reviewer/routing override on prompt rules, for example:

prefix_rule(
    pattern = ["git", "push"],
    decision = "prompt",
    reviewer = "user",
    justification = "Human approval required before pushing branches",
)

prefix_rule(
    pattern = ["terraform", "apply"],
    decision = "prompt",
    reviewer = "user",
    justification = "Infrastructure applies require explicit human approval",
)

Alternative names that would also be clear:

approvals_reviewer = "user"
approval_reviewer = "user"
approval_route = "user"

The important behavior is that a user can configure:

approvals_reviewer = "auto_review"

and then use execpolicy rules to say "these specific prefixes still go to the human approval UI."

Why this matters

Auto-review is useful for reducing approval friction, but some command families are sensitive enough that I want deterministic human review before they run, independent of Guardian's risk assessment.

Examples:

• git push
• git commit --amend
• terraform apply
• kubectl delete
• aws-vault exec
• destructive or production-affecting internal CLIs

One concrete use case is aws-vault. A user may be comfortable letting Auto-review handle most ordinary approval prompts, but want every aws-vault exec ... invocation to require explicit human approval because it crosses an AWS credential/session boundary. The important distinction is that this is not just a generic command-risk question; it is a policy boundary around when Codex gets AWS-bearing execution.

For example:

prefix_rule(
    pattern = ["aws-vault", "exec"],
    decision = "prompt",
    reviewer = "user",
    justification = "AWS credentialed command execution requires explicit human approval",
)

For these, the desired policy is not "Guardian first, maybe human if denied." It is "human approval is mandatory for this prefix." Everything else can continue using Auto-review.

Suggested semantics

• If a matching prompt rule specifies reviewer = "user", the approval request is surfaced to the normal human/user approval path even when the session's default reviewer is auto_review.
• If multiple prompt rules match and any matching rule requires user, human approval should win.
• forbidden should still be stricter than prompt as it is today.
• Rules without an explicit reviewer should preserve today's behavior and use the session/app effective approvals_reviewer.
• Requirements/managed config should be able to enforce user-only rules for certain prefixes without disabling Auto-review globally.
• The UI/history should make it clear that this was human-required by policy, not an Auto-review denial/fallback.

One product decision to make explicit: whether a per-rule human requirement should override "strict auto-review" grants. From the policy author's perspective, I would expect a rule that says reviewer = "user" to win, because it is expressing a higher assurance requirement for that command family.

Current workarounds and why they are insufficient

• Setting approvals_reviewer = "user" globally disables Auto-review for all approvals, which loses the low-friction path for ordinary operations.
• Using decision = "forbidden" blocks the command entirely, which is too strong when the user is present and willing to approve.
• PermissionRequest hooks can allow or deny before the native approval path, but they cannot currently force a request to the human approval UI while deferring the rest to Auto-review.
• Auto-review fallback proposals help when Guardian denies/aborts, but they do not cover commands that should never be auto-approved in the first place.

Related issues

• #21975 asks for optional human fallback after Auto-review deny/abort. This request is different: it asks for deterministic human routing based on execpolicy prefix rules.
• #23465 asks to expose the effective approval reviewer to PermissionRequest hooks or support an explicit defer response.
• #28833 asks for a user-facing approval signal for passive PermissionRequest notifications.
• #18840 asks for stronger manual-approval boundaries around destructive actions auto-approved by Guardian.