ask catch-all overrides more specific allow rules for same command

[AJB-ajb]

Summary

A bare ask <cmd> rule overrides more specific allow <cmd> <subcommand> rules for the same command, regardless of config ordering. I'd expect the more specific rule to win.

Repro

Config (~/.dippy/config):

allow systemctl status
ask systemctl

Test:

echo '{"tool_name":"Bash","tool_input":{"command":"systemctl status foo"}}' | dippy

Expected: allow (matches allow systemctl status)
Actual: ask (matches ask systemctl, ignoring the more specific allow rule)

Additional observations

• Order doesn't matter — allow systemctl status before or after ask systemctl gives the same result.
• Removing the ask line fixes it — without ask systemctl, the allow systemctl status rule matches correctly, and systemctl restart foo falls through to the default ask.
• Other subcommand rules work fine when there's no catch-all ask/deny for the same base command (e.g. allow typst compile works perfectly).
• This also affects deny catch-alls overriding specific allow rules (same pattern).

Use case

This matters for commands like systemctl where you want to allow read-only subcommands (status, show, list-timers, is-active, is-enabled) but prompt for mutating ones (restart, daemon-reload, enable, disable).

Dippy v0.2.7