Fixes #21665.

Why

The TUI status line is the right place for compact, glanceable session state. The original request was motivated by the need to see the active permission posture without opening /permissions or /status, especially when switching between safer and more permissive modes during a session.

This PR intentionally separates permissions from approval-mode instead of combining them into one status-line item. They answer related but different questions: permissions describes the active sandbox/profile shape, while approval-mode describes how command approvals are handled. Keeping them separate makes each item independently configurable and avoids long combined labels in an already space-constrained status line.

The tradeoff is that users who want the full permission posture in the status line need to opt into both items. In exchange, users can show only the sandbox/profile label, only the approval behavior, or both, and named user-defined profiles remain concise. Non-standard permission shapes are rendered as Custom permissions rather than trying to squeeze detailed profile contents into the status line; /status remains the fuller explanatory surface.

What changed

• Added a configurable permissions status-line item.
• Added a separate approval-mode status-line item, with approval as an alias.
• Render standard permission states compactly as Read Only, Workspace, or Full Access.
• Preserve user-defined permission profile names directly in the status line.
• Render unnamed non-standard permission shapes as Custom permissions.
• Refresh status surfaces when /permissions updates the permission profile, approval policy, or approval reviewer.
• Updated status-line preview snapshot coverage for the new items.

Verification

• cargo test -p codex-tui status_permissions_non_default_workspace_write_uses_workspace_label
• cargo test -p codex-tui permissions_selection_emits_history_cell_when_selection_changes
• cargo insta pending-snapshots --manifest-path tui/Cargo.toml