Exec approval rules are persisted globally by default (should be repo-local by default)

Summary

Exec-policy approval rules are currently easy to persist globally (~/.codex/rules/default.rules) without users realizing the scope impact. This is a security footgun.

Problems

1. Rule persistence scope is effectively global unless explicitly handled otherwise.
2. Approval UX does not clearly communicate where the approved prefix rule will be written before user approval.

Proposal

1. Add config for rule write scope with secure default:

• exec_policy_rule_write_scope = "project" | "global"
• Default: "project" (repo-local)

1. In approval prompt UI, show destination file path before approval:

• Example: Will save rule to: /repo/.codex/rules/default.rules

1. If scope is global, show explicit warning-style label:

• Scope: global (applies across repositories)

1. Keep post-approval confirmation with exact destination path.

Expected behavior

• New approvals default to repo-local persistence.
• Global persistence is explicit opt-in.
• Users can make informed approval decisions based on visible scope/path.

Rationale

This reduces accidental over-broad trust and makes security implications clear at decision time.

Related issues / distinction

• Related: #15751 (per-profile rule toggling).
• Overlap: both involve the pain of rules applying globally.
• Distinction (this issue): this requests changing where newly approved rules are persisted by default (repo-local vs global) and improving approval-time disclosure of the destination path.
• Distinction: that issue requests runtime/profile-level control over rule application after rules already exist.

If maintainers prefer, these can be merged into a single umbrella issue; this one focuses specifically on safer default persistence + clear UX disclosure.