release: Build (win32-x64) failed with EISDIR on @babel/traverse while the other targets built (v0.12.10 run, re-run without changes) #1694

What happened

The v0.12.10 release workflow run https://github.com/AltimateAI/altimate-code/actions/runs/42287757769 failed in Build (win32-x64) while the other seven platform builds and the Test job passed:

building @altimateai/altimate-code-windows-x64
error: EISDIR reading file: "/home/runner/work/altimate-code/altimate-code/node_modules/.bun/@babel+core@7.28.0+e33be1330ecc2599/node_modules/@babel/traverse"
    at /home/runner/work/altimate-code/altimate-code/node_modules/.bun/@babel+core@7.28.0+e33be1330ecc2599/node_modules/@babel/traverse
Bun v1.3.14 (Linux x64)

Build (win32-x64-baseline) in the same run, on the same commit and lockfile, built successfully, and Build (win32-x64) passed in the v0.12.9 release run. Nothing in v0.12.10 touches Babel or the build script. The failed job was re-run without a code change; this issue is the paper trail for that re-run.

What to look at

• The build step runs several bun add installs (@opentui/core, @parcel/watcher, @altimateai/altimate-core) right before bun run packages/opencode/script/build.ts --target-index=6; a package-layout change under node_modules/.bun while the bundler resolves @babel/traverse would explain reading a directory as a file.
• Whether the bundler resolves @babel/traverse to the package directory because a package.json main/exports entry is missing in that hoisted copy, and whether pinning or pre-installing it removes the race.
• Add a retry of the build step itself, or make the matrix job re-runnable on its own, so a single flaky target does not block publish for the whole release.