ci: build Codex package archives in release workflow

[bolinfest]

Why

Release CI already builds the Codex entrypoints before staging artifacts, and the package builder can now package those prebuilt binaries directly. The workflow should produce package-shaped sidecar archives from the same staged entrypoints that downstream distribution channels will eventually consume, without rebuilding codex or codex-app-server inside the packaging step.

This intentionally does not publish the new package archives as GitHub Release assets yet. The archives are kept with workflow artifacts until npm, Homebrew, install.sh, winget, and related consumers are ready to switch over.

What changed

• Adds a Build Codex package archive step to .github/workflows/rust-release.yml after target artifacts are staged.
• Runs scripts/build_codex_package.py for both release bundles:
  • primary builds codex-package-${TARGET}.tar.gz with --variant codex.
  • app-server builds codex-app-server-package-${TARGET}.tar.gz with --variant codex-app-server.
• Passes --entrypoint-bin target/${TARGET}/release/<entrypoint> so packages contain the entrypoint already built by the workflow.
• Deletes both package archive names before the final GitHub Release upload so they remain workflow artifacts only for now.

Verification

• Parsed .github/workflows/rust-release.yml with Ruby's YAML loader.

---

Stack created with Sapling. Best reviewed with ReviewStack.

• runtime: detect Codex package layout #23596
• -> ci: build Codex package archives in release workflow #23582

[viyatb-oai]

lgtm

[viyatb-oai]

One P2 follow-up on package-archive coverage across release paths.

[viyatb-oai]

[P2] This sidecar builder only runs in the main build job. promote_signed skips that job and uses stage-signed-macos, while Windows release artifacts are produced through rust-release-windows.yml, so those release paths never emit the package archives this PR is introducing. That leaves the workflow artifacts inconsistent across release modes/targets even though the PR is setting up package archives for future consumers. Could we mirror this archive step in the signed-promotion macOS path and the Windows release workflow, or factor the packaging invocation into a shared helper that all three paths call before artifact upload?

[bolinfest]

Addressed in the latest push. I factored the package-archive invocation into .github/scripts/build-codex-package-archive.sh, then wired it into all three release paths: the existing Linux/macOS build matrix, stage-signed-macos for promote_signed, and rust-release-windows.yml after Windows signing/staging. The signed macOS path packages from the target-suffixed signed files in dist/<target>, and Windows emits both primary and app-server package archives before artifact upload. Verified with Bash syntax checks, YAML parsing for both workflows, and a local signed-mac-style helper run that produced codex-package-aarch64-apple-darwin.tar.gz.