feat(acp): allow host policy to decide permission requests

[Silentpartnercoding]

Follow-up to the permission-boundary analysis in #2931.

Buzz’s generic ACP client currently selects allow_once whenever that option is offered. This change adds an injectable asynchronous permission-decision callback so the host can choose among the exact options supplied by the agent.

The callback receives the permission request and offered options. A policy decision may select only an option that was actually offered. If the policy is unavailable, times out, is cancelled, returns an error, or selects an invalid option, the client fails closed through an offered rejection option.

The focused tests cover:

• a deny decision emits a rejection response and never selects an allow option
• option kinds and IDs are preserved exactly
• string and numeric JSON-RPC request IDs
• missing policy, timeout, cancellation, callback error, and invalid selection
• response-write failure and cancellation cleanup

Trust boundary

This governs cooperative operations that cross session/request_permission. It does not provide general filesystem, subprocess, network, MCP, runtime, or operating-system containment. Runtimes that perform work without issuing a permission request remain outside this policy boundary.

Verification

• cargo test -p buzz-acp
• cargo build -p buzz-acp
• cargo fmt --check
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• focused deny-path JSON-RPC regression tests
• git diff --check

[Silentpartnercoding]

@BradGroux I implemented the narrow permission-decision callback experiment you outlined and kept the guarantee limited to cooperative session/request_permission traffic. The deny-path tests inspect the emitted JSON-RPC response and verify that no allow option is selected. I’d appreciate your review of the API shape, fail-closed behavior, and boundary wording.

[Silentpartnercoding]

Quick relevance check now that Buzz’s ACP surface has continued moving: #4066 is still mergeable against current main, and its DCO, Semgrep, and zizmor checks remain green.

Since this PR opened, #4155 and its DCO-clean replacement #4333 have added a broader Guardian proposal that also changes handle_permission_request. I reviewed the overlap rather than assuming this PR was still unique.

The distinction I see is that #4333 derives an allow/reject choice from Buzz’s fixed permission modes, while #4066 exposes a generic asynchronous host-policy callback, preserves the agent’s exact offered option IDs and kinds, and handles timeout, cancellation, policy errors, and invalid selections explicitly.

One boundary I would appreciate maintainer direction on: #4066 currently fails closed when no callback is installed, changing the historical automatic allow_once behavior. I can instead make the callback opt-in and preserve compatibility until a caller installs it, or adapt the seam to the Guardian direction if that is now preferred.

Is the generic injectable seam still useful alongside #4333, or would you prefer that this PR be revised or closed in favor of the Guardian implementation?