Preserve the provisioned macOS CLI's code-signing identity (#46495)

## Why

Existing login-keychain access rules identify the CLI as `codex`. Packaging it in an app bundle must preserve that code-signing identifier independently of the bundle identifier and provisioned App ID.

## What changed

- Sign the provisioned CLI with the identifier `codex`, retaining `com.openai.codex.cli` as its bundle identifier.
- Require the expected signing identifier and team during signature verification, and reject unexpected bundle identifiers, executable names, or package types.
- Document the identity distinction and keychain compatibility limits.

## Testing

Extend signing-driver tests to check the signing identifier, verification requirement, bundle metadata, and provisioned entitlements, and to reject altered bundle identity fields. These tests use generated credentials and stubbed native tools; they do not verify runtime keychain access or credential recovery.

GitOrigin-RevId: ab00072e48189551adb0e70008210fee6d36241d

.github/scripts/macos-signing/README.md

@@ -0,0 +1,40 @@
+# Provisioned CLI signing identity
+
+The provisioned CLI has two deliberately separate identifiers:
+
+| Purpose                               | Identifier                      |
+| ------------------------------------- | ------------------------------- |
+| Code-signing identifier               | `codex`                         |
+| Bundle identifier                     | `com.openai.codex.cli`          |
+| Provisioned App ID and keychain group | `<TeamID>.com.openai.codex.cli` |
+
+The code-signing identifier preserves access to existing login-keychain items
+whose access rules require the original CLI identity. Giving the CLI an app
+bundle must not change that identifier. The bundle identifier, App ID,
+entitlements, profile, and approved certificate remain independently validated.
+The native-verification keys use the provisioned keychain group; they do not
+replace existing login-keychain credential access rules.
+
+Changing the new binary's designated requirement to accept both identifiers
+would not make it satisfy an existing item's requirement for `codex`. Items
+created by a binary signed as `com.openai.codex.cli` are a separate compatibility
+case: restoring `codex` does not silently authorize access to those items.
+
+The signing backend must honor an explicit `--binary-identifier` when signing
+an app bundle. The wrapper signs the bundle once; rcodesign seals its metadata
+and resources while retaining `codex` as the main executable's identity.
+Release tool artifact URIs and SHA-256 digests are pinned in the signing
+environment configuration.
+
+## Release verification
+
+When `CODEX_PROVISIONED_MACOS_CANDIDATE` is enabled, tag releases automatically
+publish the provisioned archives and versioned `codex-provisioned` manifest after
+both architecture packages pass the existing signature, entitlement, profile,
+architecture, stapling, Gatekeeper, and package-smoke checks. An enabled
+provisioned build that fails verification blocks release publication.
+
+The signing-driver tests use generated credentials and stubbed native tools.
+They cover the signing command contract and failure handling. Actual keychain
+access and credential recovery across identity changes require runtime testing;
+these unit tests do not establish that behavior.