exec-guard: widen the read-only bash safe-list with vetted coreutils to cut prompt fatigue

Follow-up to #232. That PR (#246) restores the *approval prompt* for low-capability models on unrecognized bash, which fixes the hard-deny dead-end. But it means routine, genuinely-harmless commands (e.g. `sed --version`, `cut -f1 file`, `basename …`) still prompt every time. Worth deciding whether a small, carefully-vetted set of read-only coreutils should join the auto-allow `SAFE_COMMANDS` list in `extensions/loom/exec-guard/bash-risk.ts` so they run without friction for all tiers.

This is deliberately *not* part of #246 because expanding `SAFE_COMMANDS` is an auto-allow for **every** tier with no prompt, so each entry needs to be safe *regardless of arguments*.

## Proposed include (safe for any argument)

- Pure / no filesystem write: `printf`, `seq`, `basename`, `dirname`, `tr`, `true`, `false`
- Read-only filesystem (dump/transform file contents to stdout) -- these MUST also be added to the `READ_LIKE` set so the sensitive-read + workspace-jail floor still applies to their path args: `cut`, `nl`, `tac`, `rev`, `comm`, `column`, `realpath`, `readlink`

## Proposed exclude (with reasons -- keep these on the ask path)

- `sed` -- `sed -i` edits files in place (write). `sed --version` alone is harmless but the list is verb-based, not flag-based.
- `awk` -- `system()` runs shell; `print > file` writes.
- `sort` -- `-o file` writes.
- `tee` -- writes by design.
- `printenv` / `env` -- dumps the full environment, including `GALAXY_API_KEY` / `LOOM_ACTIVE_LLM_API_KEY` -> secret-leak vector.
- `xargs` -- executes an arbitrary downstream command.

## Notes / open questions

- The `READ_LIKE` coupling is the important gotcha: any file-reading verb added to `SAFE_COMMANDS` without also being in `READ_LIKE` would bypass the sensitive-path + jail floor (e.g. `cut -f1 ~/.ssh/known_hosts` would auto-allow). See the existing `readPaths` / `sensitiveReadPaths` plumbing in `bash-risk.ts` + `policy.ts`.
- Pre-existing, separate from this: `find` is already on the safe-list, so `find . -delete` (no shell meta) auto-allows a delete. Worth a flag-aware exclusion for `find -delete` / `-exec` independently of this widening.
- Alternative to per-verb allowlisting: a flag-aware classifier that allows `sed`/`sort`/etc. only when no write-flag is present. More precise but more surface to maintain; probably overkill vs. the conservative include list above.

Related: #99 (right-size tool surface for smaller models).

Start in extensions/loom/exec-guard/bash-risk.ts by reading the SAFE_COMMANDS, READ_LIKE, readPaths, and sensitiveReadPaths handling, then inspect the related plumbing in policy.ts. Add only the proposed argument-independent safe commands, preserve the read-only and sensitive-path protections, and keep the excluded commands on the approval path; consider the noted find -delete/-exec issue separately.

Written by the indexing model from the issue text.