fix: ship the directory bundle under the plugin name the portal assigned

[sherwinski]

One Line Summary

scripts/package_directory_bundle.py now writes name: "app-6a3d93b924488191bdb7eb40fc4219e6" into the bundle manifest, so the OpenAI plugin directory accepts the zip as an update to the published OneSignal listing.

Motivation

The upload of the 1.2.0 zip failed with plugin_name_mismatch: "Plugin name must match the existing plugin .codex-plugin/plugin.json. Change name from "onesignal" to "app-6a3d93b924488191bdb7eb40fc4219e6", then upload the ZIP again."

The 1.0.0 and 1.1.0 zips had no manifest, so the portal generated one for the published package and used the app identifier as name. The release zip downloaded from the portal confirms this: its manifest has "name": "app-6a3d93b924488191bdb7eb40fc4219e6", and its skill folders are identical to the 1.1.0 bundle (diff -rq reports no differences). The 1.2.0 zip was the first one with a manifest, so it was the first one the check could reject.

OpenAI support confirmed that the portal does not rename a published plugin. The alternatives were to keep the assigned name or to publish a second listing. A second listing would not keep the installs or the review history, and its first upload would need to re-submit the MCP server. This change keeps the existing listing.

Scope

• scripts/package_directory_bundle.py: a DIRECTORY_PLUGIN_NAME constant; bundle_manifest sets name to it; check_bundle_manifest rejects a bundle whose name differs. The source gate still requires a kebab-case name in the repository manifest, and the bad-plugin-name self-test still covers that.
• .codex-plugin/plugin.json keeps name: "onesignal", so the Codex marketplace install (codex plugin add onesignal@onesignal) still lists the skills as onesignal:setup. A directory install lists them as app-6a3d93b924488191bdb7eb40fc4219e6:setup. This is the namespace the published 1.1.0 listing shows today, so the directory users see no change.
• AGENT.md: the manifest row and the bundle section state that the bundle ships under the identifier of the published listing; the local-load note shows the namespace Codex lists. The history behind the identifier stays in this PR, not in the repo.
• README.md: unchanged. The namespace note can go in once the identifier is a settled decision.
• No changes to skills, references, or templates.
• No version bump. The release PR bumps the version. The 1.2.0 tag is already cut, so the fixed zip needs a 1.2.1 release (or a local build from main).

Testing

• python3 -m py_compile scripts/*.py passed.
• python3 scripts/package_directory_bundle.py --check printed bundle check passed (version 1.2.0; nothing written).
• python3 scripts/package_directory_bundle.py --self-test passed all 16 cases.
• python3 scripts/package_directory_bundle.py --out /tmp/bundle built a bundle whose manifest has name app-6a3d93b924488191bdb7eb40fc4219e6, version 1.2.0, skills ./skills/, and no mcpServers. The repository manifest still reads onesignal.
• Not tested: the portal upload itself. The next upload will confirm that the name check passes and will show whether the portal accepts a manifest version (1.2.x) lower than the version it assigned to the published package (3.0.0).

Affected code

• Skills
• Scripts
• References
• Templates
• Manifests

Checklist

• Commit subjects use conventional prefixes
• Bundle gate passes
• No secrets in the diff