fix: bump pinned Bun to 1.4.1 so x86 CPUs without AVX2 stop crashing with SIGILL

[turinglabsorg]

Issue for this PR

Closes #29039

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Bumps the pinned Bun from 1.3.14 to 1.4.1, which lowers opencode's x86 CPU floor from AVX2 (x86-64-v3) back to Bun's own baseline (SSE4.2/POPCNT, x86-64-v2). Today any x86 machine without AVX2 — Ivy Bridge and older — dies on startup with SIGILL, exit 132.

Why the existing baseline path doesn't already cover it: install.sh checks the CPU and fetches opencode-darwin-x64-baseline.zip, but on v1.18.27 that asset and opencode-darwin-x64.zip contain a byte-identical binary (27ae61d4…), which embeds Bun v1.3.14 (0d9b296a). The cause is one level up — at 1.3.14 Bun's own baseline artifact for that platform is a byte-identical copy of the AVX2 one (@oven/bun-darwin-x64@1.3.14 and @oven/bun-darwin-x64-baseline@1.3.14 are both ea2f223e…, and both SIGILL without AVX2), so --target=bun-darwin-x64-baseline had no baseline runtime to embed. From 1.4.0 that artifact runs without AVX2 (ca8a18d0… at 1.4.0, a96f31f7… at 1.4.1), so the pin bump is the entire fix — no build-script change needed.

Scope: this is an x86 baseline problem, not a macOS quirk. macOS x64 is simply the build where the duplicated artifact broke it, and Linux is unchanged by this PR because Bun 1.3.14 does ship a distinct Linux baseline runtime (@oven/bun-linux-x64-baseline a8f9ebd1… vs @oven/bun-linux-x64 9fd36f87…), so opencode-linux-x64-baseline.tar.gz already has the correct floor.

.github/actions/setup-bun derives its download URL from packageManager, so CI picks the bump up automatically, and CONTRIBUTING already states Bun 1.3+ as the requirement.

How did you verify your code works?

Test machine: Xeon E5-1620 v2 (Ivy Bridge — AVX, no AVX2/FMA/BMI2), macOS 12.7.6.

• Reproduced it: both shipped v1.18.27 macOS assets SIGILL; the binaries inside the two zips have the same sha256; the embedded runtime string is Bun v1.3.14 (0d9b296a).
• Ran each @oven/bun-darwin-x64* runtime directly on that CPU: the 1.3.14 pair crashes, 1.4.0 and 1.4.1 print their version and exit 0.
• Compiled a hello-world with Bun 1.4.1 (--target=bun-darwin-x64) and ran it there: works.
• Ran opencode 1.18.27's own bundle on the Bun 1.4.1 runtime: the TUI renders (OpenTUI's libopentui.dylib loads and paints the UI, not just --version), opencode serve answers HTTP on /config, startup ~1.2s.
• Checked for a second blocker: libfff_c does ship AVX2 and AVX-512 code, but it dispatches on CPUID at runtime and loads and runs fine on this CPU.

Not verified: a release build produced at 1.4.1, which needs the CI toolchain — worth a CI run before merge. Separately, running the extracted bundle outside a compiled executable needs two path fixes that are unrelated to this change and that a real build does not need (an asset import carrying with { type: "file" }, and OPENCODE_WORKER_PATH pointing at worker.ts while the bundle emits worker.js).

Screenshots / recordings

N/A — not a UI change.

Checklist

• I have tested my changes locally — at runtime level as described above, not a release build
• I have not included unrelated changes in this PR

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[turinglabsorg]

Verification update, and a note on how general this is.

This isn't a macOS-specific patch — it's about the x86 baseline. Since Bun 1.4.0 the macOS-x64 artifact runs without AVX2, so pinning it puts opencode's CPU floor at Bun's own x86-64 baseline (SSE4.2/POPCNT, x86-64-v2) instead of today's AVX2 (v3). Any pre-Haswell x86 machine gains, and it's the same floor opencode-linux-x64-baseline already has — macOS x64 was just the build where Bun 1.3.14's baseline artifact was a byte-identical copy of the AVX2 one, so --target=bun-darwin-x64-baseline had nothing baseline to embed.

What I verified on a pre-AVX2 box (Xeon E5-1620 v2 — Ivy Bridge: AVX, no AVX2/FMA/BMI2; macOS 12.7.6), running opencode 1.18.27's own bundle on the Bun 1.4.1 runtime:

• the TUI renders — OpenTUI's libopentui.dylib loads and paints the UI, not just --version
• opencode serve answers HTTP on /config
• startup ~1.2s

Two caveats stated plainly: I ran the shipped bundle on the 1.4.1 runtime rather than a release build produced at 1.4.1, so a CI build is still worth doing before merge; and running the extracted bundle outside a compiled executable needs two path fixes unrelated to the CPU issue (an asset import carrying with { type: "file" }, and the build-time OPENCODE_WORKER_PATH pointing at worker.ts while the bundle emits worker.js) — a real build doesn't need either.

In case anyone suspects a second blocker: libfff_c does ship AVX2 and AVX-512 code, but it dispatches on CPUID at runtime — it loads and runs fine on this CPU.