fix(s03): ask for approval when bash touches paths outside the workspace - #601

Fixes #494

Problem

read_file / write_file / edit_file prompt through Gate 2/3 before
touching paths outside the workspace, but the equivalent operations through
bash (cat /etc/passwd, tar -czf backup.tgz ../project, cd /etc && ...)
run silently — no deny, no approval. The three READMEs describe Gate 2 as
covering reads/writes outside the workspace, so the shell path currently
bypasses the user-approval contract.

Solution

Following the approval-based boundary contract settled in #482/#484 (Gate 2
owns the workspace boundary, hard safe_path stays out of the handlers), this
adds one Gate 2 rule for bash:

• prompts when a shell command references an absolute path outside the
  workspace (e.g. /etc/passwd), or a ../ relative escape
• /dev/null is exempted as a common output sink
• absolute paths inside the workspace (as printed in the system prompt)
  stay silent
• no sandbox claims: it routes the decision to the same Allow? [y/N] Gate 3
  the file tools already use

Changes

• s03_permission/code.py: add references_outside_workspace() (+ regexes)
  and one PERMISSION_RULES entry (+23 lines)
• tests/test_permission_command_words.py: add 8 cases for the new rule
  (+41 lines) — outside-workspace commands prompt, inside-workspace absolute
  paths and /dev/null stay silent

Testing

• pytest tests/test_permission_command_words.py → 203 passed
  (195 pre-existing + 8 new)
• full suite: no new failures vs main

Notes for Reviewer

• The rule is heuristic by design (tokenizing shell is out of scope for a
  teaching chapter); it errs toward asking, never toward silently allowing.
• AI disclosure (per CONTRIBUTING §5): prepared with the help of an AI coding
  agent; I have read and stand behind every line.