`--permission-mode dontAsk`: `cp`/`mv` refuse any option token (including bare `--`) while the flagless form runs; `rm` is unaffected

## Summary
Under `--permission-mode dontAsk`, with Bash allow rules for `cp`, `mv`, and
`rm` at the same breadth (e.g. `Bash(cp:*)`, `Bash(mv:*)`, `Bash(rm:*)`),
`cp` and `mv` are refused whenever the command carries *any* option token,
while their flagless (bare) forms run. `rm` is unaffected — `rm -f` and
`rm -rf` both run normally under the identical rule shape.

## Repro table (measured on Claude Code 2.1.251, run E)
| command | result |
|---|---|
| `cp -f` | REFUSED |
| `cp -v` | REFUSED |
| `cp --` | REFUSED |
| `cp` (bare) | RAN |
| `mv -v` | REFUSED |
| `mv` (bare) | RAN |
| `rm -f` | RAN |
| `rm -rf` | RAN |

Also confirmed:
- `cp -f` with relative paths — still REFUSED (not about absolute vs. relative paths)
- `cp -f` repeated as the last of several arms in the same session — still REFUSED (deterministic, not drift/a race)

## Why this reads as a matcher artifact, not a safety policy
- `cp --` is refused. `--` is the POSIX end-of-options marker: it carries no
semantics a permission policy could plausibly want to withhold, yet it
trips the identical refusal as `-f`.
- `rm -rf` — by a wide margin the most destructive of the four commands —
runs unflagged under the identical Bash allow-rule shape. A rule
deliberately withholding force/destructive flags would refuse `rm` first,
not leave it alone while blocking an inert `cp --`.

Together these point at an implementation bug in how the `dontAsk`
permission matcher classifies `cp`/`mv` invocations carrying any token
after the command name, rather than a considered decision to gate those
two commands' options specifically.

## Environment
- `--permission-mode dontAsk`
- Bash allow rules for `cp`, `mv`, `rm` at the same breadth
- Measured on Claude Code 2.1.251

## Cost
Our own project guidance tells every agent to always pass a force flag on
`cp`/`mv`, specifically because those commands may be aliased to `-i` on a
developer's shell, which would otherwise hang a non-interactive session
forever waiting on a y/n prompt it cannot answer. Under `dontAsk` that
guidance is unfollowable for these two commands, and we had to write a
standing flagless-form exemption into our own docs to work around it.

## Related
Searched before filing; no exact duplicate found. Related but distinct:
#16449 (quoted arguments starting with `-` misparsed), #30519 (permission
matching megathread). Neither covers this cp/mv-vs-rm asymmetry or the
option-token-vs-bare-form split.

Reproduce the reported command matrix with --permission-mode dontAsk and the matching Bash allow rules, comparing cp, mv, and rm with and without option tokens. Then trace the permission matcher handling these invocations. Done means cp and mv option forms behave consistently with their bare forms while rm retains its current behavior, with regression coverage for the reported cases.

Escrito por el modelo de indexación a partir del texto del issue.