fix(ci): publish darwin-x86-64 (Intel macOS) — retire macos-13 + fix bun bootstrap

Problems

1. macos-13 runner retired. GitHub fully retired the macos-13 (Intel) hosted runner image in Dec 2025. The darwin-x86-64 matrix entries (added in 533c10d) targeted it, so every Intel-macOS job sat queued for 17h+ and never ran. 10 runs were piled up. All other platforms were fine.

2. Intel-macOS bun bootstrap clobbered. Once a real runner picked up the job, it failed at bun install ("Bun's postinstall script was not run"). Root cause: the Hetzner registry has no darwin-x86-64 bun yet, so pantry install (registry-based) drops a placeholder .exe text stub and repoints pantry/.bin/bun at it — clobbering the genuine upstream binary the action's TS installer had already placed. Every later bun install then runs the stub and dies. arm64/linux were spared only because the registry already had their bun.

Fixes

• Runners: macos-13 → macos-15-intel (GA Intel label) across build.yml, build-versions.yml, build-registry.yml, sync-binaries.yml.
• installer.ts: linkBinaries() extracted and made idempotent — re-asserted on the already-installed path too, so a genuine binary always (re)owns its .bin/<name> link even if another installer dropped a stub over it.
• action: after pantry install, re-run the TS installer for each system dep (no-op download when present) so it re-links .bin/<name> to the real binary — a registry stub for a not-yet-published platform can never win. Fixes the Intel bootstrap with no per-workflow workaround; applies to all build/sync workflows since they share the action.

Verification

On a real macos-15-intel runner: sync-binaries darwin-x86-64 job succeeds; bun.sh darwin-x86-64 published to Hetzner; tarball downloads HTTP 200 with matching SHA256, and the binary inside is a genuine Mach-O 64-bit x86_64. Also reproduced the clobber→recover locally.

🤖 Generated with Claude Code