ci: add gated macOS preview updater feed promotion

[kalvinnchau]

Summary

• Promote each successful, signed macOS preview prerelease automatically to preview-feed/latest.json after publication. Scheduled and manual build runs use the same gate; explicit promote_version remains available for controlled recovery. Candidate-only Windows/Linux runs cannot publish the feed.
• Before replacing the rolling manifest, download the immutable archive/signature; verify both Minisign signatures against the public key embedded in the client, require the candidate binary to contain the updater endpoint/key, and reject full-SemVer rollback or changed same-version metadata. Read back the GitHub API asset. Keep stable-feed reserved and legacy block/buzz untouched.
• Accept CLI 2.11.x signatures, which lack an authenticated version field. Residual risk: a feed-response attacker can advertise a higher version while replaying an older authentic signed archive. The coordinated CLI/updater 2.12.x bump must emit and enforce the signed version at promotion and in the client.

Validation and rollout limits

• At 1a6e98c9, node --test tests/integration/preview-feed.test.mjs passes 3/3 (including workflow-graph assertions for automatic/manual paths and crypto/rollback fixtures); Biome and commit/push hooks pass. git diff --check origin/main...HEAD passes.
• Full integration suite: 133/161 pass; 28 local fixture/launcher failures including spawned fake rustc/pnpm EACCES. Preview-feed and packaging gate tests passed. Not claiming a clean full suite.
• No live feed publication or production-signed old→new installation attempted. First eligible auto-promotion starts when this workflow reaches main, provided an updater-enabled build is published. Before broad preview distribution, verify the production signing key, exact public endpoint and a controlled Apple-signed old→new install; otherwise manual DMG recovery may be needed. GitHub asset replacement may briefly return 404; see docs/releases.md.

[wesbillman]

Star Lord — automated source review via Wes’s account

One actionable public-material finding; no additional concrete implementation defect found. Mantis independently reviewed the signature, rollback and workflow-publication paths at the same pins; I checked those conclusions against the source. This is a non-blocking comment review, not approval or merge authorization.

• Head: 1a6e98c9bc8737b08399b7d7a53ff206df561841
• Base: 32982724223d8090441415ed89ddf7cb7a8d286e

P2 — Remove deployment-specific identity details from the public commit metadata

All four outgoing commits (4acf081c, 130ac469, a53a3f1b, 1a6e98c9) expose an internal relay deployment domain and its environment-scoped agent identifier in the author/committer email and Signed-off-by trailer. This is part of the public PR surface even though it is not in the file diff. Please have the contributor replace that deployment-scoped address with their verified public-safe contribution identity throughout these commits, preserving actual authorship and truthful DCO certification. Do not substitute another person’s identity or remove required sign-offs. I am deliberately not repeating the address here. This concrete disclosure is what keeps the overall change below the repository’s 9/10 readiness bar.

Implementation assessment

The production change is bounded to the promotion job and one verifier. It retains main-only release publication and candidate-build exclusion, serializes promotion with macOS releases, verifies both Minisign signatures before uploading the manifest, checks the candidate’s embedded key/endpoint, compares all canonical preview-version components using BigInt, preserves identical same-version manifests, and reads back the uploaded API asset. Three Node integration tests are added; no browser cases are added or removed.

I am not reopening these explicitly documented rollout choices as newly discovered defects:

• The reviewed head does not yet contain the updater integration from #312. Its build cannot satisfy the new embedded-key/endpoint gate until that dependency lands; promotion fails closed rather than making an updater-less artifact eligible. The matching key/endpoint in #312 were checked separately at 727792ccdf5a322d9fa1462078cd63a044dfec19, not treated as part of this head.
• CLI 2.11.x signatures do not authenticate the advertised version. Signature verification here is not end-to-end anti-rollback protection against a modified feed response; the coordinated signer/client change and acceptance of the stated preview risk remain outstanding.
• A failed --clobber upload may leave the rolling asset absent and require operator recovery. API readback is not public-endpoint or installed-client validation. Automatic promotion before broad-distribution acceptance is the stated rollout policy, not proof that installation works.

Validation limits

Source only: no PR code, tests, builds, release workflows, app installs or production writes were executed. The description has no attached images. Existing deployment-specific release-documentation references also remain, but are unchanged from the base rather than introduced by this diff.

At the single CI snapshot, JavaScript, Rust/integration and browser jobs were still running; DCO, Semgrep and zizmor had passed, and Windows native validation was skipped. No timing artifacts were available at that snapshot, so job counts, elapsed/summed execution and slowest-test/file regressions could not be assessed. The PR reports 3/3 focused local tests and 133/161 full integration tests, with 28 local fixture/launcher failures; these are author-reported, not independently reproduced results.

Production-key verification, exact public-endpoint checks, controlled Apple-signed old→new installation, relaunch/version confirmation, failure/retry behavior on disposable clients and human acceptance remain unverified. No UI focus behavior is changed or validated by this PR review.