Headless: move git commit/PR instructions out of the bash tool description #156

Part of the spec in #160.

Problem

tool/bash.txt is about 2.4k tokens (9.6k chars). About 1.5k of that is the "Committing changes with git" and "Creating pull requests" sections, which go out on every request of every headless run.

Whether a headless run may commit, push or open PRs is the caller's decision, and it depends on the workflow. Many headless uses only read: review, analysis, explanation, triage. For those, a built-in commit/PR procedure costs tokens on every step and pushes the model toward write actions the caller didn't ask for. Usage data from production headless runs points the same way: git commit appears in <1% of review-type executions and gh pr create in none.

Git "safety" prose in a tool description is also not a control. Prompt text is not a security boundary, so dangerous actions must be blocked by permissions in the environment config, not described in the prompt.

Proposal

1. The bash tool description describes only the tool: what it runs, the working directory, the timeout, output truncation, quoting/paths and chaining commands. No commit/PR procedure, no git safety or policy rules, and no opt-in that brings them back.
2. Block dangerous commands with permissions. Document a permission.bash example that denies force pushes, hook skipping (--no-verify) and git config changes, including the pattern syntax and precedence (the last matching rule wins; each command in a bash call is matched separately).
3. Document the caller's responsibility. Callers whose agents should commit or open PRs supply their own procedure through skills, AGENTS.md or instructions, and run the CLI in an isolated environment with scoped credentials.

Acceptance

• The default bash description contains no commit/PR procedure and no git policy text (test).
• The description is ≤ ~1k tokens (measured: 3,710 chars ≈ 0.93k tokens, down from ≈ 2.4k).
• A test shows the documented permission.bash example denies git push --force…, git push -f, git commit --no-verify… and git config …, including inside a && b, while allowing git status and ordinary pushes and commits.
• The docs (both READMEs) describe restricting dangerous commands with permission.bash. The CHANGELOG notes the behaviour change at release time.