Routines: existing .claude/settings.json wildcard permission rule for compound PowerShell command not honored on scheduled run (no prompt should appear)

## Summary

In the Claude Code desktop app's **Routines** (scheduled tasks) feature, a project-level `permissions.allow` wildcard rule in `.claude/settings.json` that matches a compound PowerShell command (`cd ""; python -m *`) is not honored on every scheduled run — the routine still prompts "Allow once / Deny" for the exact command the wildcard should cover. A newly-added rule for a different subcommand of the *same* underlying script (in the *same* routine, same run) worked correctly and also offered an "Always allow" button, while the two pre-existing rules did not offer "Always allow" at all — only "Allow once"/"Deny" — suggesting the permission matcher considered them already "covered" by something, without actually applying that coverage.

This defeats the purpose of a scheduled/unattended Routine: a task meant to run every 30 minutes with no human present stalls on a permission prompt that nobody is there to click.

## Environment

- Claude Code desktop app (Windows 11)
- Feature: Routines (scheduled tasks), local task running on a `*/30 * * * *` cron schedule
- Project has both `.claude/settings.json` (shared/project) and `.claude/settings.local.json`, the latter with `"defaultMode": "auto"`

## Steps to reproduce

1. Create a scheduled Routine whose prompt runs a PowerShell tool call shaped like:
`cd "C:\some\dir"; python -m some_module some_subcommand --flag value`
2. Add to the project's `.claude/settings.json`:
```json
"PowerShell(cd \"C:\some\dir\"; python -m some_module some_subcommand *)"
```
3. Let the routine fire on its schedule (not a manually-typed interactive message).

## Expected

The compound command matches the wildcard rule and runs without any prompt, exactly as it would for a simpler `Bash(cmd *)`/`PowerShell(cmd *)` rule.

## Actual

- The routine still shows an "Allow once / Deny" prompt for the command, even though the wildcard rule was added to `.claude/settings.json` *hours before* the run in question (added at 00:12, prompt still appeared at a run at 14:11 the same day).
- No "Always allow" option is offered for that prompt — only "Allow once" and "Deny".
- In the *same run*, a third PowerShell command (for a different subcommand of the same script, added to `.claude/settings.json` for the first time just before this run) correctly triggered an "Allow once / Always allow / Deny" prompt with all three options, and clicking through worked as expected.

This suggests the routine's permission check either isn't reading the project `.claude/settings.json` wildcard rules consistently, or there's a matcher bug specific to compound `cd ...; ...` PowerShell commands, or a stale/narrower rule in `.claude/settings.local.json` (added earlier via a previous "Always allow" click, before the routine's commands were changed to prepend `cd "";`) is short-circuiting the match without actually satisfying it — which would also explain why "Always allow" wasn't offered (the system may think it's "already handled").

## Impact

A Routine intended to run fully unattended every 30 minutes cannot do so reliably — it silently blocks on a permission dialog with nobody to click it, so scheduled runs effectively stop making progress until a human happens to open the app and click through.

## Request

- Please confirm whether project-level `.claude/settings.json` wildcard `allow` rules are read for scheduled Routine executions the same way they are for interactive sessions.
- Please check whether an older, narrower rule (e.g. an exact-match rule from a previous "Always allow" click, made before a command's shape changed) can suppress the "Always allow" offer for a newer, technically-non-matching invocation of a similar command, without actually granting the permission.