Allow dangerous-command review when sandbox approvals are disabled (#59120)

## Why

Setting granular `sandbox_approval` to `false` also blocked approval requests for dangerous commands such as `rm -f`, even when they requested no additional permissions. Reviewing a dangerous command should remain possible within the existing permission profile.

## What changed

Allow heuristic dangerous-command approval requests with `sandbox_approval = false` when execution stays within current permissions. Do not propose reusable execution-policy amendments for these approvals, since reusable allow rules can bypass the sandbox on later calls.

Keep escalation requests, explicit policy rules, and Windows execution without required sandbox protection subject to their existing approval restrictions. Clarify the meaning of `sandbox_approval` in the protocol and generated schemas.

## Testing

Add coverage for POSIX and Windows approval decisions, approval and denial of deletion commands, preservation of read-only restrictions, and separate dangerous-command approval after turn-scoped or session-scoped write grants.

GitOrigin-RevId: 90adc137c7b7d3f3ee68efb1f6bea531229e7834

codex-rs/protocol/src/protocol.rs

@@ -1187,8 +1187,9 @@ pub enum AskForApproval {
 
 #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Serialize, Deserialize, JsonSchema, TS)]
 pub struct GranularApprovalConfig {
-    /// Whether to allow shell command approval requests, including inline
+    /// Whether to allow sandbox escalation approval requests, including inline
     /// `with_additional_permissions` and `require_escalated` requests.
+    /// Dangerous commands can still request approval within existing permissions.
     pub sandbox_approval: bool,
     /// Whether to allow prompts triggered by execpolicy `prompt` rules.
     pub rules: bool,