[FEATURE]: let plugins gate the auto-approve path via a permission hook in PermissionV2 #34327

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

What. Fire a plugin hook inside PermissionV2 (packages/core/src/permission.ts, used by every tool — bash/edit/webfetch/read/…) at the point where an effect resolves to allow/ask/deny, letting a plugin adjust it: downgrade an allow to ask (prompt the human) or deny, or upgrade an ask to allow.

Why. A plugin today can only observe a tool call via tool.execute.before, which runs after permission resolution and can deny only by throwing (a tool error the agent sees). That covers "block", but there's no way for a plugin to turn a would-auto-approve call into an interactive human prompt — the thing that makes a "consult something before auto-approving" guardrail useful.

Note the permission.ask hook is already declared in the plugin SDK (packages/plugin/src/index.ts: (input, output: { status: "ask" | "deny" | "allow" })), but nothing in core triggers it, and the live tool path is PermissionV2, not the V1 Permission.ask that session/processor.ts uses. So the hook is effectively dormant for tools.

Concretely. In PermissionV2.assert (or the internal effect computation), after computing the effect and before the allow/deny/ask branch, trigger a plugin hook with the request + a mutable { status }, then honor the (possibly adjusted) status. With no plugin registered it's a no-op, so behavior is unchanged.

Use case / motivation. I maintain an external guardrails plugin (openguardrails-instrumentation-opencode) that evaluates each tool call against agent-configured text/regex rules (and optionally a model) and currently enforces via tool.execute.before. It can block, but it can't ask — a first-class ask from a plugin would let guardrails request human confirmation instead of hard-denying. Happy to send the PR if the approach sounds good.