permission profiles: expose availability to clients

[viyatb-oai]

Why

permissionProfile/list currently advertises every built-in and configured profile even when effective enterprise requirements prevent selecting it. That forces each client to reconstruct policy from lower-level requirement fields, which is easy to miss and difficult to keep consistent.

The catalog should remain complete so clients can explain that an option was disabled by an administrator, while also reporting whether each profile is selectable.

What

• Add an allowed field to each permission profile summary.
• Build a shared catalog from the effective config and current requirements, including allowed_sandbox_modes, allowed_permissions, and filesystem restrictions.
• Use the shared catalog in app-server and the TUI so disallowed profiles remain visible but cannot be selected.
• Use the canonical :danger-full-access profile ID in the TUI.
• Update the app-server schemas, API documentation, behavioral tests, and TUI snapshots.

Scope

This PR targets main directly and is independent of #24852. It preserves the current behavior where built-in profiles are constrained by sandbox-mode requirements and allowed_permissions applies to configured profiles.

Testing

• just test -p codex-core permission_profile_catalog_marks_profiles_disallowed_by_requirements
• just test -p codex-app-server permission_profile_list
• just test -p codex-app-server-protocol
• just test -p codex-tui profile_permissions
• just fix -p codex-core
• just fix -p codex-app-server-protocol
• just fix -p codex-app-server
• just fix -p codex-tui
• just fmt

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[joeytrasatti-openai]

Rebased onto current main and validated the complete allowed/disallowed catalog across core, app-server, protocol, and TUI coverage.

[joeytrasatti-openai]

Catalog now retains disallowed entries and derives availability from the effective layered config. Focused tests and all CI checks are green.