Permission precedence: `allow` wildcard overrides `ask` rules

Bug Description

The ask permission rules are supposed to take precedence over allow rules (docs state evaluation order is deny → ask → allow, first match wins). However, a wildcard allow rule like Bash(*) overrides more specific ask patterns, auto-approving commands that should prompt.

Reproduction

Settings file (.claude/settings.local.json):

{
  "permissions": {
    "ask": [
      "Bash(*zigzag-admin*)",
      "Bash(*aws configure set*)",
      "Bash(*AWS_ACCESS_KEY_ID*)",
      "Bash(*AWS_SECRET_ACCESS_KEY*)",
      "Bash(*~/.aws/credentials*)",
      "Bash(*.aws/credentials*)"
    ],
    "allow": [
      "Bash(*)"
    ]
  }
}

Expected behavior: Commands matching ask patterns (e.g. containing zigzag-admin) should prompt for confirmation. All other bash commands should auto-approve via Bash(*) in allow.

Actual behavior: All bash commands auto-approve, including those matching ask patterns. The ask rules are effectively ignored when Bash(*) is present in allow.

Context

This makes it impossible to configure "allow everything except these specific patterns" — which is a common use case for projects where most CLI commands are safe but a few (e.g. admin/write operations, credential access) should require explicit approval.

Environment

• macOS (Darwin 25.2.0)
• Claude Code CLI