[URGENT] fix(dev): qualify Turbopack runtime boundaries (phase 5)

[backryun]

Summary

Completes the implementation side of Phase 5 for #12074 by fixing the two exact runtime boundaries reproduced on the post-Phase-4b release head:

• keep tiktoken external so Node selects its CommonJS loader instead of Turbopack bundling the ESM tiktoken_bg.wasm import;
• retain tiktoken_bg.wasm in standalone output tracing;
• anchor the optional SQLite loader to the real process entrypoint and invoke it through Reflect.apply, preventing Turbopack from rewriting the dynamic request into its in-bundle resolver.

This does not add warning ignores or mix provider/dependency/catalog work into the phase.

Reproduction and result

Qualification was repeated from an empty Next cache and isolated SQLite directory on release head 2e17161ea with OMNIROUTE_USE_TURBOPACK=1.

Before this patch:

• both better-sqlite3 and node:sqlite failed with Cannot find module as expression is too dynamic, forcing the sql.js fallback;
• /api/providers returned 500 because tiktoken_bg.wasm was missing during module evaluation;
• the same failures were repeated across provider/settings/instrumentation import paths.

After this patch:

• cold start reached the Turbopack listening state in 4.350 s;
• the runtime selected better-sqlite3 directly;
• the targeted log scan found no dynamic-module error, missing tiktoken WASM, Turbopack panic, createRequire parse failure, critical-dependency flood, or MaxListenersExceededWarning;
• graceful SIGINT drained requests, checkpointed SQLite, stopped the ChatGPT Web runtime and logger resources, and exited cleanly.

Route	Status	First request
/dashboard/providers	200	3.174 s
/api/health/ping	200	0.373 s
/api/providers	200	0.600 s
/api/settings	200	0.218 s
/api/v1/models	200	1.534 s

Three real provider-page source edits/restoration returned 200 in 59 ms / 61 ms / 77 ms. RSS moved from 4,805,408 KiB after the first HMR graph activation to 4,822,272 KiB after the third cycle (+16,864 KiB), rather than showing the previous runaway pattern.

After the representative routes and three HMR cycles:

• RSS: 4,822,272 KiB
• total dev output: 2,389,080 KiB
• cache: 1,337,708 KiB
• server output: 934,828 KiB
• static output: 115,092 KiB

All temporary source probes were restored. The isolated DBs and approximately 4.6 GiB of before/after generated caches were deleted after measurement.

Automated validation

• focused Node regression set: 41/41 passed
• Vitest: 50 files, 463/463 passed (serial workers with an isolated DB)
• npm run typecheck:core
• Prettier, ESLint, git diff --check, pre-commit documentation sync and quality gates

I also started the full npm run test:unit command. It did not complete: the pre-existing warmupScheduler/circuitBreakerFactory* group remained pending for more than five minutes and blocked the remaining runner queue, so I interrupted it rather than claiming a full-suite pass. The changed DB/config tests and both non-overlapping focused/Vitest suites above are green.

Scope

• next.config.mjs
• src/lib/db/adapters/runtimeRequire.ts
• tests/unit/turbopack-runtime-boundaries-12074.test.ts

[backryun]

The two failed unit shards are inherited release contract drift from #12247, not failures in this PR's Turbopack/runtime-boundary files.

Exact failures:

• shard 3/4: native-codex-turn-pin-10379.test.ts — isPinnedTargetModelScopedUnusable distinguishes model lockout from provider/connection outages
• shard 4/4: native-codex-turn-pin-model-scoped-fallback.test.ts — Turn pin NOT released when provider in global cooldown

#12247 correctly changed provider-level cooldowns to require PROVIDER_PROFILES.*.providerFailureThreshold failures, but both older tests still recorded one failure and assumed global cooldown was active. I reproduced the same 2/15 failures locally on the release head.

The test-only alignment is isolated in #12259 to preserve this Phase 5 PR's bundler-only scope. The corrected turn-pin tests plus the new provider-window suites pass 38/38 locally. Once #12259 merges, this PR should be rebased/refreshed and the two inherited shards rerun.

[diegosouzapw]

Validated in local merge-train on 192.168.0.113 — train of #12258 #12262 #12166 #12281 #11259 #11950 merged clean onto origin/release/v3.8.51 (f5e7095):

• Run 1 (/opt/actions-runner-omniroute-5, train tip 85cd9119): typecheck:core, file-size, complexity ×2, changelog-integrity — all green; the test:unit step was killed by a CI job landing on that runner mid-train (workspace clobbered — infra, documented risk).
• Run 2 (/srv/omniroute-train/.claude/worktrees/mt-green1, same 6 PRs re-boarded, fresh npm ci): unit 35768/35805 pass (/tmp/mt-unit2.log), vitest 464/465 (/tmp/mt-vitest2.log).
• Every failure is a latency/timing assert (bounded-time, event-loop lag, cooldown windows) on a box that was never idle (3 active CI runner workers throughout). Discriminated per merge-gates §3: the 3 persistent titles reproduce identically on the pure base tip on the same box (/tmp/mt-base-isolated.log, BASE_ISOLATED_EXIT=1 — same tests, same asserts), 5 more titles reproduce on the pure base on the devbox, and the single vitest failure (provider-family-combos) also fails on main's nightly without any of these PRs. Inherited/infra — not introduced by this train.