Support persistent command deny-rules in permissions-config.json

[jkuoppa]

Is your feature request related to a problem? Please describe.

permissions-config.json (per-directory tool_approvals) only supports allow rules (kind: "read" | "write" | "commands" | "mcp" | "memory"). There is no way to persistently mark a command family (e.g. a specific CLI tool) as always-denied for a given trusted location. The only related mechanism, --deny-tool, is a per-invocation CLI flag (see #2722) - it doesn't persist across sessions and has its own matching bugs (denies ALL reads instead of the pattern, bypassable via shell(cat ...)).

Users who want to categorically block a whole command family (cloud CLIs, destructive tools, package managers, etc.) across all sessions in a directory currently have no durable option - they must remember to reject the prompt every single time, or avoid the tool being available at all.

Describe the solution you'd like

Extend the tool_approvals schema (or add a sibling array, e.g. tool_denials) in permissions-config.json to support explicit deny rules scoped by location, symmetric with today's allow rules:

{
  "locations": {
    "C:\\path\\to\\project": {
      "tool_approvals": [ ... ],
      "tool_denials": [
        {
          "kind": "commands",
          "commandIdentifiers": ["some-cli"]
        }
      ]
    }
  }
}

• Deny rules should always take precedence over allow rules and over the default "ask" behavior (deny > ask > allow, matching Claude Code's precedence model).
• Should match the full command family (e.g. some-cli, some-cli subcommand, etc.), not just literal substrings, to avoid the bypass issues described in --deny-tool="read(...)" blocks ALL file reads regardless of pattern; no persistent permission profiles for non-interactive mode #2722.
• Ideally manageable via a CLI/slash command too (e.g. /deny-tool some-cli), mirroring /reset-allowed-tools.

Describe alternatives you've considered

• --deny-tool per invocation - not persistent, and has matching bugs (--deny-tool="read(...)" blocks ALL file reads regardless of pattern; no persistent permission profiles for non-interactive mode #2722).
• Manually rejecting prompts every time - error-prone, no durable guarantee.

Additional context

Related: #2722 (deny-tool matching bugs, no persistent profiles), #307 (closed) Comprehensive Permissions System Improvements Proposal, #179 (globally configurable allowed tools).