HQ's branded native compilation logged an ENOENT while reading .stx/bundle-tmp/out/<hash>-<pid>-15/.stx-client-<hash>-<pid>-15.js. The process continued through the development fallback, so a passing unrelated native test is not proof that the client bundle was complete.
The shared bundler's tempBuildName() combines the content hash, PID and a module-local counter. Separate JS isolates or loaded copies have independent counters; workers share the PID. Two real Node-compatible Bun workers importing the source both return the identical <hash>-<pid>-1. The new deterministic regression fails on the original code (four existing cases pass, one new worker case fails). Loading two independent module copies reproduces the collision too.
Give each build an owned temporary namespace across workers and loaded copies. Keep normal shared-request/cache behavior, actual bundle contents and failure reporting; do not clear HQ caches or suppress the ENOENT. Verify the worker case, concurrent complete bundles, client-bundler tests and normal package release, then consume the published package in HQ.
Observed during https://github.com/stacksjs/hq.training/issues/346; independent of the pointer implementation in https://github.com/stacksjs/stx/issues/2137 and https://github.com/stacksjs/hq.training/issues/339.