fix(guardrails): hold a wrapped destructive confirm to the args it previewed (#89)

[ifahimreza]

Closes #89
Refs #63

What

Two guardrail fixes, both in the "an agent is told the wrong thing" family.

A wrapped destructive tool can no longer be confirmed with different arguments than it previewed. And a capability denial now says so, instead of being reported as one of the site owner's switches.

Why

The bind. Saddle_Approval::gate() takes a bind parameter precisely so that confirmation-relevant arguments are part of the token's identity — it is what stops a "move to trash" preview being confirmed into a permanent delete. Saddle_Integrations::executor() never passed it. The only thing holding a confirm to its preview was target, the first of id / post_id / attachment_id found in the input, and the $delegate closure captured the confirm call's $input.

So on any partner tool that takes an id plus a payload — the common shape — the payload was unbound:

1. preview with {post_id: 12, description: "the one the user approved"} → preview + token, nothing mutated
2. confirm with {post_id: 12, description: "something else", confirm_token: …} → the second one executes

The user approves one change and gets another. That is the two-step confirm doing the opposite of its job, and "no destructive action without a two-step confirm" is the third non-negotiable.

It was invisible in the suite because tests/integrations-test.php's synthetic destructive tool takes a single argument that is the target — the one shape where the existing target hash incidentally binds everything.

The denial. denial_reason() covered paused / not-authenticated / tool-disabled / tier and then returned null. A capability denial — already recorded under that exact name by log_denial() — reached the agent as the generic "None of Saddle's site-wide gates blocked this…" paragraph, which names three fixes and not the real one. The fix is a different WordPress account; no access level or toggle touches it.

How

• bind is a sha256 of the full argument set minus confirm_token, key-sorted recursively so a client that reorders its JSON doesn't break a legitimate confirm. confirm_token is excluded for the reason the original comment gives: the preview call doesn't carry one and the confirm call does.
• target stays the bare id so the activity-log line remains a readable #12 rather than a hash. Target keys widened past the original three and put behind saddle_integration_target_keys — with the bind in place, a key missing from that list costs legibility, never safety.
• Saddle_Capabilities::permission() records the capability each ability asks for as it registers. One line, one site: free, Pro and the integration wrappers all build their callback there, so no registration site changes. denial_reason() checks it in the same order permission() does, so the owner's switches still outrank it.

Testing

• composer test — 518 tests, 1828 assertions, green (1 pre-existing skip)
• composer lint — 0 errors; the 3 warnings are pre-existing and in files this PR doesn't touch
• The bind regression was pinned as a failing test first, and it named the symptom: test_destructive_wrapper_confirm_cannot_change_the_arguments_it_previewed
• Its other half is pinned too — unchanged arguments must still confirm, or the gate would be unusable on every id-bearing partner tool
• Three denial_reason() cases: the capability denial is explained, a disabled tool still outranks it, and a properly-privileged account gets no claim at all
• No notices or warnings with WP_DEBUG on

No CI in this repo, so "green" here means the commands above were run locally.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GkZr73cqaSesHRDG89Yy8S