core: add host_executable integration coverage

[bolinfest]

Why

host_executable() is now wired into both execpolicy preflight and zsh-fork, but the remaining question from the rollout was whether the real tool entry points still exercised that path end to end after the refactors landed.

The follow-up caller audit did not uncover another production path that needed to opt in. The next useful cleanup is to lock in the audited behavior with integration coverage, so future changes to preflight parsing or tool plumbing do not silently drop host_executable() resolution for explicit absolute commands.

What Changed

• added an expect_exec_approval() helper in core/tests/suite/exec_policy.rs for asserting the real approval flow
• added a Unix integration test for shell_command showing an explicit absolute git path matched by host_executable() plus a basename prefix_rule() produces a policy prompt
• added a Unix integration test for exec_command covering the same path with an explicit /bin/bash wrapper, which keeps the test on the shell-wrapper parsing path that preflight currently understands
• both tests deny the approval and assert the resulting tool output contains rejected by user, so they verify the real tool/runtime flow rather than only ExecPolicyManager unit behavior

Verification

• cargo test -p codex-core --test all host_executable_rules
• just fix -p codex-core
• cargo shear

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: efc5556781

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Do not strip script extensions in executable safety key

On Windows this helper now strips .cmd/.bat/.com and is used by is_safe_to_call_with_exec, so a path like C:\temp\git.cmd status is classified the same as git status. That makes user-controlled script wrappers eligible for the safe-command fast path (and therefore auto-allow behavior in render_decision_for_unmatched_command when approval policy is UnlessTrusted), which is an approval bypass regression compared to the previous behavior that did not match git.cmd to git.

Useful? React with 👍 / 👎.