fix(release): install both macOS CPU variants so Intel builds get node-pty

[mvanhorn]

Summary

• The macOS Electron release job installed dependencies with a plain pnpm install --frozen-lockfile, which resolves CPU-specific optional deps (notably node-pty) for the runner's own architecture only. The x64 artifact built on an arm64 runner therefore shipped without a usable Intel node-pty, and the terminal failed on Intel Macs.
• This installs both CPU variants on macOS and adds a regression test that asserts the workflow keeps doing so.

Why

• Intel Mac users hit a broken terminal in the released build; the arm64 build was fine, which is why it was easy to miss.
• The failure lives in release CI, not in app code, so nothing in the existing test suite covered it. Without a test asserting the workflow shape, the next person editing the install step can silently reintroduce it.

Issue

• Closes [Bug]: macOS Intel Darwin Binary missing #2831

Scope

• .github/workflows/release-macos-aarch64.yml: split the single Install dependencies step into a macOS step that runs pnpm install --frozen-lockfile --cpu=arm64 --cpu=x64 and a Linux/Windows step that keeps the existing pnpm install --frozen-lockfile, selected by matrix.os_type.
• apps/desktop/electron/electron-builder-config.test.mjs: new test installs both macOS CPU variants for Electron releases, which parses the release workflow and asserts the macOS matrix covers both electron-macos-arm64 and electron-macos-x64 and that the macOS install step requests both CPUs.

Out of scope

• No change to node-pty itself, its version, or how the app loads it.
• No change to Linux or Windows install behavior; those keep the original single-CPU install.
• No change to signing, notarization, or publishing steps.
• Not addressing any other cross-arch dependency; this fixes the install step that caused the reported terminal failure.

Testing

Ran the Electron distribution config suite locally, which now includes the new workflow assertion.

Ran

• node --test electron/electron-builder-config.test.mjs (from apps/desktop)

Result

• pass/fail: pass
• 5 tests, 5 passing, 0 failing, including the new installs both macOS CPU variants for Electron releases.
• if fail, exact files/errors: n/a

CI status

• pass: the config test suite above passes locally.
• code-related failures: none observed.
• external/env/auth blockers: I cannot run the actual macOS release job from a fork; it needs the repo's signing and notarization secrets. The regression test asserts the workflow's shape instead, which is the part that regressed.

Manual verification

1. Check out this branch and run node --test electron/electron-builder-config.test.mjs from apps/desktop; the new case passes.
2. Revert only the workflow hunk (restore the single pnpm install --frozen-lockfile) and re-run; the new test fails, showing it actually pins the behavior rather than passing vacuously.
3. On a real release run, confirm the macOS install step logs both --cpu=arm64 and --cpu=x64, and that the x64 artifact contains an Intel node-pty binary.

Evidence

• N/A (CI-configuration change; the regression proof is the test in step 2 above, which fails against the previous workflow and passes with this change).

Risk

• Low. The install command changes only on macOS, and adding a second --cpu target is additive: arm64 resolution is unchanged, x64 binaries are added alongside.
• Install time on the macOS runner grows slightly because both optional-dependency sets are fetched.
• If a dependency ever ships an arm64 build but no x64 build, the macOS install would fail loudly at CI time rather than producing a silently broken artifact. I consider that the better failure mode, but it is a behavior change worth knowing about.

Rollback

• Revert this PR. The two hunks are independent of each other and of the rest of the release pipeline: restoring the single Install dependencies step returns the previous behavior exactly, and dropping the test removes the assertion. No state, cache, or published artifact needs cleanup.

[vercel]

@mvanhorn is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, v0	Aug 1, 2026 2:04pm

[mvanhorn]

The four red Vercel checks here aren't from this change — they're all returning a vercel.com/git/authorize link rather than a build failure, which is Vercel declining to build a fork PR without team authorization. Nothing in the diff touches the app builds.

Flagging it so it doesn't read as a broken PR. Happy to rebase or do anything else that helps, but I can't clear those from my side.