The asset-emission assertion was the false positive flagged in
tab-supervisor.ts: the new pattern intentionally does not bundle the
worker as an asset of the supervisor — it is added as a separate
`--compile` entrypoint in build-binary.ts, and runtime is covered by
`omp --smoke-test` (sync worker).
Replaces it with two cheap static checks that defend the two halves
that actually make the worker survive `bun build --compile`:
1. tab-supervisor.ts branches on `isCompiledBinary()` and uses the
exact `--root`-relative literal at the `new Worker(...)` site
that Bun's `--compile` analyzer can discover, while keeping the
`new URL("./tab-worker-entry.ts", import.meta.url)` branch for
dev/source spawns.
2. scripts/build-binary.ts lists the same worker as an explicit
additional `--compile` entrypoint so Bun emits it into bunfs.
The Worker spawn in spawnTabWorker used `new Worker(new URL(...).href, ...)`
through a local variable, which Bun's --compile static analysis does not
recognize. As a result, tab-worker-entry.ts was never embedded in single-file
binaries (v14.5.13+), and the worker thread failed to load its entry at
/$bunfs/root/tab-worker-entry.ts, surfacing as the user-visible
"Timed out initializing browser tab worker".
Switch to a `with { type: "file" }` import of the entry module so the
bundler discovers and embeds it in both dev and compiled targets.
Regression test asserts `Bun.build` emits tab-worker-entry as an asset
alongside the tab-supervisor entry point — the same static-analysis pass
that powers `bun build --compile`.
can1357