ci(audio-capture): cross-compile darwin-x64 prebuild on arm64, drop macos-13 runner

[qqqys]

What

The macos-13 (Intel x64) audio prebuild job routinely stalls in the GitHub-hosted runner queue for 20+ min — the Intel pool is scarce and on GitHub's deprecation path — while every other platform finishes in under a minute. It blocks the dependent collect job and the Release run that calls this workflow. See #5642 for evidence (the job sits queued with no runner assigned and 0 steps started, even after the rest of the run completes).

This drops the macos-13 matrix entry and cross-compiles the darwin-x64 slice on the existing macos-14 (arm64) runner instead.

Why it works

binding.gyp links only universal macOS frameworks (CoreAudio / AudioToolbox / AVFoundation / ...) with no hardcoded architecture, so clang -arch x86_64 cross-compiles cleanly. The Build step now runs prebuildify for the native arm64 slice and, on macOS only, again with --arch x64.

Verification

Locally on Apple Silicon:

$ npm run prebuildify -- --arch x64
$ file prebuilds/darwin-x64/@qwen-code+audio-capture.node
prebuilds/darwin-x64/@qwen-code+audio-capture.node: Mach-O 64-bit bundle x86_64
$ file prebuilds/darwin-arm64/@qwen-code+audio-capture.node
prebuilds/darwin-arm64/@qwen-code+audio-capture.node: Mach-O 64-bit bundle arm64

Both slices build in one ~40s job.

Downstream safety

• create-standalone-package.js gates on the file prebuilds/darwin-x64/*.node existing (hasNativePrebuild), not on runner or artifact names — the cross-compiled slice satisfies it.
• collect merges every per-platform artifact via the prebuilds-* glob with merge-multiple, so the x64 slice (now inside the macos-14 artifact) is still collected.
• No other workflow or script references macos-13.

Closes #5642

[yiliang114]

LGTM

[qwen-code-ci-bot]

Thanks for the PR! The change itself looks focused and well-motivated — dropping the scarce macos-13 runner and cross-compiling x64 on arm64 is a clean approach.

However, the PR body doesn't follow our PR template. A few required sections are missing:

• Reviewer Test Plan — including the "Tested on" OS table so reviewers know which platforms were validated
• Risk & Scope — what could go wrong, what's out of scope
• 中文说明 — the Chinese translation <details> block

Could you update the PR description to match the template? It helps reviewers (and future-you reading git log) understand the change quickly.

---

感谢这个 PR！改动本身很聚焦，动机也很合理——用 arm64 runner 交叉编译 x64 来替代排队 20+ 分钟的 macos-13 runner，方案很干净。

不过 PR 正文没有按照我们的 PR 模板 来写，缺少几个必填部分：

• Reviewer Test Plan — 包括 "Tested on" 平台表格，方便 reviewer 快速确认哪些平台验证过
• Risk & Scope — 风险点、未覆盖的范围
• 中文说明 — <details> 里的中文翻译

麻烦按模板补充一下 PR 描述，方便 reviewer 和后续维护者快速理解改动。谢谢！

fixed

[wenshao]

[Suggestion] After this change the single macos-14 matrix entry produces both darwin-arm64/ and darwin-x64/ prebuilds, but the upload-artifact name downstream (line 72) is prebuilds-${{ matrix.os }}-${{ matrix.arch }}, which evaluates to prebuilds-macos-14-arm64. The automated pipeline is unaffected (the collect job uses pattern: 'prebuilds-*' with merge-multiple: true), but a maintainer downloading that artifact to debug a CI failure would be surprised to find x64 binaries inside an arm64-named archive.

Consider either:

1. Adding a matrix variable (e.g., artifact_suffix: 'arm64+x64') and using name: 'prebuilds-${{ matrix.os }}-${{ matrix.artifact_suffix || matrix.arch }}', or
2. Appending a +x64 suffix conditionally for the macOS entry.

— qwen3.7-max via Qwen Code /review