Dangerous-command detection misses plain rm and sudo-wrapped rm variants

Plain rm invocations with operands appear to miss the dangerous-command heuristic unless the command is exactly rm and the second argument is exactly -f or -rf.

Examples that appear to be missed today:

rm file.txt
rm -fr dir
rm -r -f dir
/bin/rm -rf dir
sudo -n rm -rf dir

This matters in request-based approval flows when filesystem protection is unrestricted or external. If the unmatched command is not classified as dangerous, the policy path can allow it without surfacing an approval prompt.

A narrow fix would be to:

• normalize the executable basename before matching rm / sudo
• treat rm with operands as dangerous, including split or combined short flags
• skip common sudo options before checking the wrapped command
• keep no-op/error forms such as rm or rm -rf without operands out of the dangerous set

I have a proposed narrow patch on branch fallintoplace:fix-rm-danger-detection. It intentionally avoids adding destructive git handling, since previous history suggests git was intentionally removed from this classifier. The branch only hardens the existing rm / sudo contract and adds focused regression coverage.

Suggested labels: bug, sandbox, exec, CLI