fix: prompt for unsafe commands on Windows

[bolinfest]

This fixes a bug where Codex was allowing unsafe commands to run when SandboxPolicy::ReadOnly was set on Windows (but should not have).

There is some understandable confusion in the codebase, as we currently lack a variant of SandboxPolicy to express the case where "there is no sandbox available, not because the user did --yolo, but because there just isn't one, sorry."

Because many places in our code require a SandboxPolicy as a parameter, rather than pass Option<SandboxPolicy> around everywhere, we simply default to SandboxPolicy::ReadOnly on Windows. On Mac and Linux, we provide an actual read-only sandbox such that we can allow commands to run freely and rely on the sandbox to prevent anything bad from happening. However, the same assumption does not apply on Windows.

Ultimately, the proper fix is to introduce a new variant to SandboxPolicy to accurately represent the current sandbox state, but for now, I ported the requires_initial_appoval() function in is_dangerous_command.rs that contained the existing logic over to render_decision_for_unmatched_command() in exec_policy.rs and cleaned it up. Note that this function was originally introduced in #6380 for unified exec, but things have changed such that it has been repurposed for, and used exclusively by, execpolicy. The migrated function is now private to exec_policy.rs so it is not picked up by anyone else.

To verify this fixes the existing behavior, I added only the verify_approval_requirement_for_unsafe_powershell_command() test from this PR on main and verified that it failed as expected, returning ExecApprovalRequirement::Skip instead of ExecApprovalRequirement::NeedsApproval for pwsh -Command 'echo hi @(calc)' on Windows. With the changes to render_decision_for_unmatched_command(), now it passes.