Bash tool with capability-UX integration

[psschwei]

Part of #1020

Stretch goal for v0.6.0

The problem

Bash is where capability questions stop being abstract: "may I write to this directory?", "may I run git push?", "may I reach the network?" The Python tool can get away with permissive defaults for many cases; Bash cannot. We need a first-class Bash tool, sensible safety defaults, and an "allow once / allow always" capability UX wired through the harness. Because the underlying machinery is shared, the Python tool should inherit this UX for free.

Acceptable implementation

• A BashEnvironment built on the sandbox runtime + capability policy, not a parallel implementation.
• A Bash tool capturing stdout, stderr, exit code, timeout status; configurable working directory; the same ExecutionResult shape as the Python tool.
• Safety defaults that refuse, by default: sudo, rm -rf / and relatives, writes outside allowed roots, destructive git operations, interactive commands. "Refuse by default" means "user can opt in via capability policy" — not "blocked forever".
• A Bash requirements bundle in the same spirit as the Python one: non-interactive, no sudo, no out-of-root writes, under timeout, under output limits, expected file/git-diff artifacts exist. Expected to grow reactively.
• End-to-end wiring of "allow once / allow always" from capability policy through the harness, such that the Python tool picks up the same flow without changes at its call site.

Design questions worth resolving

• Where does "obviously unsafe" get decided? Argv pattern-matching is fragile; capability enforcement plus a short denylist for interactive/sudo-type calls is probably the right mix. Draw the seam.
• Is approval scoped to a tool call, a session, a project, or a user? Session-by-default with an explicit path to persistent allow-always is a reasonable starting point, but the answer needs design before implementation.
• How does a Python-only app get the capability-UX benefits without its author thinking about Bash?