feat: introduce Permissions

[bolinfest]

Why

We currently carry multiple permission-related concepts directly on Config for shell/unified-exec behavior (approval_policy, sandbox_policy, network, shell_environment_policy, windows_sandbox_mode).

Consolidating these into one in-memory struct makes permission handling easier to reason about and sets up the next step: supporting named permission profiles ([permissions.PROFILE_NAME]) without changing behavior now.

This change is mostly mechanical: it updates existing callsites to go through config.permissions, but it does not yet refactor those callsites to take a single Permissions value in places where multiple permission fields are still threaded separately.

This PR intentionally does not change the on-disk config.toml format yet and keeps compatibility with legacy config keys.

What Changed

• Introduced Permissions in core/src/config/mod.rs.
• Added Config::permissions and moved effective runtime permission fields under it:
  • approval_policy
  • sandbox_policy
  • network
  • shell_environment_policy
  • windows_sandbox_mode
• Updated config loading/building so these effective values are still derived from the same existing config inputs and constraints.
• Updated Windows sandbox helpers/resolution to read/write via permissions.
• Threaded the new field through all permission consumers across core runtime, app-server, CLI/exec, TUI, and sandbox summary code.
• Updated affected tests to reference config.permissions.*.
• Renamed the struct/field from EffectivePermissions/effective_permissions to Permissions/permissions and aligned variable naming accordingly.

Verification

• just fix -p codex-core -p codex-tui -p codex-cli -p codex-app-server -p codex-exec -p codex-utils-sandbox-summary
• cargo build -p codex-core -p codex-tui -p codex-cli -p codex-app-server -p codex-exec -p codex-utils-sandbox-summary

[owenlin0]

naming nit: should we just call this Permissions? is the Effective part necessary?