test(build): pin the bundler flag to OMNIROUTE_USE_TURBOPACK, the contract it implements

[ntdatt812]

The red test

Unit Tests fast-path fails on every branch:

✖ resolveNextBuildBundlerFlag automatically disables Turbopack and uses Webpack under Bun
  AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
    actual:   '--turbopack'
    expected: '--webpack'

Why I concluded the test is the stale side

I want to be explicit about this, because "align the assertion to current behaviour" is
exactly how a real defect gets buried, and I nearly left this one alone. The evidence:

1. The function never implements the rule. resolveNextBuildBundlerFlag does not
   read process.versions.bun — there is no runtime branch to have regressed. As far as
   the (squashed) history goes back, there never was one.
2. The documented contract disagrees with the test.
   docs/reference/ENVIRONMENT.md describes OMNIROUTE_USE_TURBOPACK as defaulting to
   1, with 0 the escape hatch "on Windows, when running into native binding /
   bundler-compat incompatibilities, or on RAM-constrained machines". No Bun clause.
3. Every webpack fallback in CI is memory-motivated, not Bun-motivated.
   nightly-compat.yml pins 0 with a long comment about a Node 26 OOM kill on the
   runner; electron-release.yml pins 0 for the linux matrix leg. build.yml,
   ci.yml and quality.yml all pin 1.
4. Nothing in the repo builds under Bun. bun appears only in
   check:known-symbols and test:bun:db. There is no next build path that runs on it.
5. The test's second assertion is the strongest tell: it demands that an explicit
   OMNIROUTE_USE_TURBOPACK=1 be ignored under Bun. That directly contradicts the
   variable being the operator's control — and CI is an operator that sets it to 1.

If I have this backwards — if Turbopack genuinely cannot build under Bun < 1.4 —
then the fix belongs in resolveNextBuildBundlerFlag as a version gate, not in the
test, and I will happily rewrite this PR that way. Say the word. What I did not want to
do is leave the gate red on a contradiction nobody had adjudicated.

What this PR does

Rewrites the case to pin the contract the function actually implements, and to keep a
real guard rather than just going green:

for (const bun of [undefined, "1.1.20", "1.3.14"]) {
  …
  resolveNextBuildBundlerFlag({})                                → "--turbopack"
  resolveNextBuildBundlerFlag({ OMNIROUTE_USE_TURBOPACK: "1" })  → "--turbopack"
  resolveNextBuildBundlerFlag({ OMNIROUTE_USE_TURBOPACK: "0" })  → "--webpack"
}

Three runtimes × three env states. A hidden runtime-sniffing override cannot come back
without failing here, and the assertion message names the runtime it fired on. The old
assertion could not have caught that — it demanded the override this now forbids.

The function's comment said "Turbopack is the default (on Node.js and Bun 1.4+)", which
is what made the stale assertion look load-bearing. Nothing implements that version
gate, so the comment now states the env-only rule and why it is env-only.

Verification

# base branch
✖ resolveNextBuildBundlerFlag automatically disables Turbopack and uses Webpack under Bun
ℹ tests 4  ℹ pass 3  ℹ fail 1

# with this change
ℹ tests 4  ℹ pass 4  ℹ fail 0

The new guard bites. I re-added a runtime override by hand
(if (process.versions.bun) return "--webpack"; above the env check):

✖ resolveNextBuildBundlerFlag is decided by OMNIROUTE_USE_TURBOPACK alone, not by the runtime
  AssertionError [ERR_ASSERTION]: bun=1.1.20
    actual:   '--webpack'
    expected: '--turbopack'

npx eslint <both files>   # 0 errors
npx prettier --write      # clean

I deliberately left one pre-existing formatting deviation in bun-support.test.ts
untouched (prettier wants to expand the dummyBunDb.query literal) so the diff stays
on the case being fixed.

No behaviour change: the only production edit is a comment.