fix(release): recover lost macOS ticket connections

[Astro-Han]

Summary

Desktop Nightly 38513006217 stopped on both macOS architectures after Apple accepted their DMG notarizations. stapler staple lost the CloudKit ticket connection (NSURLErrorDomain Code=-1005) and exited 68, so the complete Desktop publication was blocked despite successful notarization. The earlier Intel Host startup check passed in this run.

Nightly and formal Desktop workflows now use one stapling entry point. It retries only exit 68 with that observed transport error, at most three attempts with 10/20-second waits and a two-minute command bound. Each attempt remains visible in the logs; other failures stop immediately. Successful stapling must pass stapler validate before packaging verification and publication continue. The formal workflow's duplicate validation moves into this shared gate. Release identity, signing, notarization, Gatekeeper assessment and final package verification remain enforced.

The existing one-shot calls could not recover this confirmed network failure. A shared script keeps that recovery rule out of duplicated workflow shell blocks. The separate Intel Host startup timeout is not changed.

CI also exposed a pre-existing inventory drift on main: the Astryx path/table already listed 335 files, while its generated Markdown summary still counted 334. Regenerate only that summary line through the existing generator so the required CI gate can validate this release repair.

Verification

• The captured exit-68/network-loss regression fails with a one-shot stapler call and passes with recovery, followed by validation of the same artifact. Persistent network loss fails after three attempts; missing tickets, other exit codes and validation failures remain fatal.
• Both publication workflow callers are checked to invoke the shared gate after notarization completes.
• A command-level probe ran the actual CLI entry point with an external xcrun fixture: the first staple exited 68 with the captured network error; after the real 10-second wait, the second staple and validation succeeded against the identical path. This verifies launcher and subprocess error handling, not Apple service availability.
• Clean dependency install and build passed. All 219 release checks, 85 scoped recovery/workflow/planner checks, format, lint and whitespace checks passed locally.
• The inventory check reproduced main's stale summary. Regeneration changed only the count line; inventory verification and all 23 existing inventory tests then passed.
• The network failure is from a native macOS runner. Recovery tests control the external xcrun boundary; a fresh native Nightly after review and merge is still required to confirm the complete publication path. No live Apple credentials or release artifacts were used in these local recovery tests.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Codex investigated the failed publication, implemented the shared recovery gate and regressions, and ran local checks.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

At 2449dc637fa2c73a7a0fb98175f0a96e097a092d, I found no P0–P3 defect in this eight-file release repair.

The failure premise is confirmed by the original Desktop Nightly run: both macOS architectures reached Accepted, then final-DMG stapling failed with the CloudKit connection-loss error and exit 68. The repair targets that observed transport failure, not rejected notarization or missing tickets.

scripts/staple-macos-artifact.mjs retries only numeric exit 68 accompanied by NSURLErrorDomain Code=-1005, at most three staple attempts, with ten- and twenty-second waits. Each subprocess has a 120-second timeout. It validates the same artifact after successful stapling; failed validation, missing tickets, other exit codes, process timeouts and spawn failures remain fatal. Both workflows call it after notarytool submit --wait. Moving the formal workflow's validation into this helper does not remove it. Release identity, signing, Gatekeeper, package verification and successful-platform prerequisites for staging/publication remain in place. Final checksums are still written after artifact verification.

I exercised the actual Node CLI entry point with an external xcrun fixture and a path containing spaces. Network recovery takes the real ten-second wait and then validates the identical path. Persistent connection loss stops after exactly three attempts and thirty seconds of waits, without validation. Missing tickets and other exit codes stop after one call; a validation failure returns failure without retry. The original one-shot command fails on the same first network response. These tests prove the subprocess/launcher recovery contract, not availability of Apple's service.

The helper and its tests independently select the release-contract CI lane. The inventory document is byte-identical to current main's corrected 335/331 version and passes regeneration checks. No protocol file or compatibility epoch changes.

Validation: fresh dependency installation/patches, normal clean build and production renderer pass. The normal release check passes 218 tests with one platform-required macOS ZIP test skipped; all 52 focused recovery/workflow/planner tests and 23 inventory tests pass. Formatting and whitespace checks pass. The exact-head hosted checks are green, including CI, and the branch merges cleanly with main ecd4dba8a6fcbdc8846e0b4e4de7f6ffbd3ccb8f.

No live Apple credentials, native notarization/stapling or publication were used locally. A fresh native Nightly remains necessary to qualify the complete repaired publication path; the hosted PR tests do not establish that result.