support PreToolUse allow and ask permissionDecision

[abhinav-oai]

What

Adds support for PreToolUse hook permissionDecision: "allow" and permissionDecision: "ask" outcomes while preserving the existing deny behavior.

1. PreToolUse hook output is parsed once in codex-hooks.
2. The hook runtime returns either a block, no directive, or a typed permission directive.
3. ToolRegistry attaches that directive to the tool invocation before dispatch.
4. Shell-like tools carry it into the shared ToolOrchestrator, where it is applied beside the existing approval requirement:
   • allow approves the request without running permission prompts or guardian review
   • ask requests a user prompt directly, suppressing guardian review and PermissionRequest hook evaluation for that forced prompt
5. MCP calls receive the same directive at their approval boundary and apply equivalent behavior there.

Design decisions

• Build on the existing ApprovalRequest / centralized approval-routing work instead of adding another parallel decision system. The new directive changes routing policy, while the existing approval machinery still owns prompt construction and decision handling.
• Keep PreToolUse responsible only for the hook verdict. The directive is attached to the invocation once and consumed at the approval boundary, which avoids re-running hooks or plumbing bespoke flags through unrelated layers.
• Preserve hard forbids. allow bypasses prompts and guardian review, but it does not override an approval requirement that is already classified as Forbidden.
• Keep ask explicitly user-facing. It bypasses guardian review and cached/automatic approval shortcuts so the hook can reliably force a human confirmation path.
• Leave defer out of scope for now because this change only adds the Claude-compatible behaviors we can map cleanly onto the current approval model.