Windows ARM64 native builds fail: bun:ffi unavailable in stable Bun, bun-pty ships x64-only DLL

Summary

Building and running opencode natively on Windows on ARM (arm64, e.g. Snapdragon X laptops) hits two runtime gaps. The build itself works with Bun 1.4.0 (packages/opencode/script/build.ts already lists a win32 arm64 target), but the TUI and #pty shell sessions break.

1. TUI renderer needs bun:ffi, which stable Bun disables on windows-aarch64

OpenTUI (@opentui/core) loads a native opentui.dll through bun:ffi. Stable Bun 1.3.x ships bun:ffi compiled out on windows-aarch64 (TinyCC has no ARM64 backend), so the TUI fails at startup with:

Failed to initialize OpenTUI render library: bun:ffi dlopen() is not available in this build (TinyCC is disabled)

Bun 1.4.0+ ships an engine-native FFI that works on Windows ARM64, so this is resolved by requiring Bun >= 1.4.0 there.

2. bun-pty ships only an x64 Windows DLL

bun-pty@0.4.8's Windows binary (rust_pty.dll) is x64-only and cannot be loaded by an arm64 process, breaking shell sessions via #pty. bun-pty is a Rust crate using the portable-pty backend and cross-compiles cleanly — it just needs a win32-arm64 build published (repo: github.com/sursaone/bun-pty).

Suggested fixes

• Document and/or enforce Bun >= 1.4.0 for windows-arm64 (CI matrix + docs).
• bun-pty: publish a windows-arm64 build, or have opencode vendor/swap the DLL for arm64 (the current local workaround does exactly this via a postinstall step).

Verified context

• Native single-file build (opencode-windows-arm64) succeeds with Bun 1.4.0 (arm64) on Windows 11 ARM64.
• Everything else in the toolchain (esbuild, tree-sitter, @opentui/core-win32-arm64, etc.) resolves for arm64 out of the box.

Happy to send the local patch (postinstall DLL swap + install script windows-arm64 combo) as a PR if useful.