feat(core): add CommandInterceptor exec/open hook to ShellExtensions

[hartsock]

Addresses #1183.

What

Adds an optional CommandInterceptor component to ShellExtensions with two
default-allow hooks, before_exec(program, args) and before_open(path, write),
letting an embedding host deny external command execution and file opens
in-process. Default behavior is unchanged.

Why

See #1183. In short: embedders cannot currently confine command
execution in-process, and the path-separator dispatch branch (/bin/rm,
./x) bypasses PATH and the builtin table, defeating any name/PATH-based gate.
This is the minimal additive seam to close that.

How

• New sub-trait extensions::CommandInterceptor (mirrors ErrorFormatter),
  collected as ShellExtensions::CommandInterceptor, with
  DefaultCommandInterceptor (allow-all). ShellExtensionsImpl gains a second
  type parameter that defaults to DefaultCommandInterceptor, so
  DefaultShellExtensions and all existing call sites are source-compatible.
• Shell<SE> stores a command_interceptor: SE::CommandInterceptor instance
  (parallel to error_formatter), wired through CreateOptions/the builder,
  new, Default, and Clone. New accessor Shell::command_interceptor().
• before_exec is invoked once, at the top of
  commands::execute_external_command — the single funnel for both dispatch
  branches. Denials return a new ErrorKind::ExecDenied(program, reason)
  (mapped to exit code 126, "cannot execute").
• before_open is invoked in Shell::open_file (covers redirections and
  source/.). Denials return an io::Error(PermissionDenied), which the
  existing RedirectionFailure / FailedSourcingFile wrapping reports cleanly.
  Write-intent is derived from the OpenOptions (best-effort, fail-safe toward
  "write").

Test plan

• New integration test brush-core/tests/command_interceptor_tests.rs:
  • denies a bare-name command (rm, PATH-resolved);
  • denies an absolute-path command (/bin/rm), proving the
    path-separator branch is now hooked (the load-bearing case);
  • allows a permitted command (/bin/true);
  • denies an output redirection writing outside an allowed directory while
    allowing one inside it;
  • allows a read-only source open (proving the write flag is threaded).
• Full existing suite (cargo test --workspace, including the YAML bash-compat
  cases and the redirection cases) passes unchanged — the default-allow impl is
  behavior-preserving.
• cargo fmt --check and cargo clippy --workspace --all-targets -D warnings
  are clean.

Compatibility / risk

Additive only. ShellExtensionsImpl's new type parameter is defaulted, so
downstream type X = ShellExtensionsImpl<MyFormatter> keeps compiling. No
behavior change for any shell that does not opt in to a custom interceptor.

Open questions for the maintainer

• Naming: CommandInterceptor vs. SecurityPolicy vs. Sandbox? Hook names
  before_exec/before_open vs. check_exec/check_open?
• Should before_open get its own ErrorKind::OpenDenied rather than reusing a
  PermissionDenied io::Error? (We chose the latter to fit the existing
  open-file error flow.)
• Would you want the hook to also see the resolved argv0 / process-group
  policy, or is (program, args) sufficient?
• Should there be a parallel async hook, or is sync acceptable given spawns are
  composed synchronously?

---

Per the project's AI Policy: this change was authored with AI assistance and
reviewed/tested by a human contributor; the commit carries an Assisted-by:
trailer accordingly.

[hartsock]

Committed to landing this one — I'll keep the branch rebased on main so it stays mergeable whenever you have a chance to review. Thanks!

[hartsock]

Full CI is green on my fork for this branch — all 30 jobs pass across macOS, Windows, Linux (x86_64/aarch64/musl), wasm32, and the OS-target distros: https://github.com/hartsock/brush/actions/runs/27522097280

[hartsock]

@reubeno just a note from me to say I am highly invested in this patch. I am working on an Object Capability security harness and I think working inside a shell like Brush is a major breakthrough in future security work that will ONLY be possible with a project like this. Thanks for taking on such a BEAST and doing a good job managing the community!

[reubeno]

@reubeno just a note from me to say I am highly invested in this patch. I am working on an Object Capability security harness and I think working inside a shell like Brush is a major breakthrough in future security work that will ONLY be possible with a project like this. Thanks for taking on such a BEAST and doing a good job managing the community!

Thanks for checking in on this @hartsock, and also for your patience! I and we appreciate your enthusiasm and contributions 😄.

I'm also very supportive of getting these kinds of hooks added -- I think it's just a matter of making sure we can arrive at the right API surface. June was rough for me, but I should hopefully have more time in the next few weeks to engage with you here on more detailed review.