beta.36+ leaves __VITE_PRELOAD__ unresolved in production build output, breaking every lazy QRL at runtime

## Summary Starting at `@qwik.dev/core`/`@qwik.dev/router` `2.0.0-beta.36`, production builds succeed and look clean, but every interactive element that needs a lazy-loaded QRL (any click handler, any `<Link>` navigation) throws `ReferenceError: __VITE_PRELOAD__ is not defined` in the browser at click time — the click silently does nothing (no navigation, no handler fires). `2.0.0-beta.35` never reproduces this, regardless of Vite version. Latest published (`beta.38`, 2026-07-16) still reproduces it — no fix currently available. This is a **hard blocker** on upgrading past `beta.35` for any app affected by #8450 (dynamic-route `<Link>`/`nav()` bundle-prefetch mismatch) — that bug's actual fix landed (apparently incidentally) in `beta.37`'s `prefetch-route.ts`, but it's unusable because `beta.37`/`beta.38` both carry this regression. ## Environment - `@qwik.dev/core` / `@qwik.dev/router`: reproduced on `2.0.0-beta.36`, `2.0.0-beta.37`, `2.0.0-beta.38` (latest as of 2026-08-18). Never reproduces on `2.0.0-beta.35`. - Vite: reproduces independent of Vite version (tested `8.0.13`, `8.0.16`) — this is not the separate `vite@8.1.x`+rolldown `chunkFileNames` issue (that one throws at build time; this one builds clean and fails at runtime). - Dev server (`vite dev` / `bun run dev`) does **not** reproduce — chunks are served unbundled there, so the marker-substitution step this bug affects never runs. A dev-server smoke test gives false confidence; only a real production build + real browser click reproduces it. ## Reproduction 1. Scaffold or take any Qwik City/Router app with at least one `<Link>` or `onClick$` handler that resolves to a separate lazy chunk. 2. Pin `@qwik.dev/core`/`@qwik.dev/router` to `2.0.0-beta.36` or later (no caret — a caret range can silently pull this in on a routine `pnpm install`, which is how we first hit it in production). 3. `vite build` (production build). 4. `grep -rl "__VITE_PRELOAD__" dist/build/*.js | wc -l` — non-zero on `beta.36`+ (~260-273 chunks in our apps), always `0` on `beta.35`. 5. Serve the built output and click any interactive element needing a lazy QRL — `ReferenceError: __VITE_PRELOAD__ is not defined` in the browser console, click does nothing. ## What we believe is happening `__VITE_PRELOAD__` is a build-time placeholder Vite's `importAnalysisBuild` plugin injects at every dynamic-`import()` call site, then sweeps and replaces per-chunk with the real dependency list during `renderChunk`. Something changed in the `beta.36` optimizer around how/when Qwik's lazy chunks are emitted such that Vite's sweep no longer sees a large fraction of them — they ship with the literal placeholder string still in place. We haven't diffed the optimizer source to pin the exact change (unlike #8450, where we did trace the fix to a specific commit) — flagging this as our working theory, not a confirmed root cause. ## Cross-repo confirmation Independently bisected in two separate, unrelated production apps (both Qwik 2, both on this same stack) with the same result each time: - First hit and bisected 2026-07-02: confirmed clean on `beta.35` regardless of Vite version, broken on `beta.36`/`beta.37`. - Reconfirmed 2026-07-08 in a second, independent app: fresh bump to `beta.36` on a scratch branch reproduced the identical unswept-marker grep result. - Reconfirmed again 2026-08-18 against `beta.38` (latest): still 273 unswept chunks. ## Workaround Pin `@qwik.dev/core` and `@qwik.dev/router` to `2.0.0-beta.35` exactly (no caret range). Verify with the grep in step 4 after every build — a dev-server-only smoke test is not sufficient proof of a safe upgrade. ## Possibly related [#8506](https://github.com/QwikDev/qwik/issues/8506) (Vite 8 support) may be in the same fault family (both involve Vite-8-era chunk-emission behavior) but we have not confirmed they're the same root cause — flagging as a maybe, not a duplicate claim. Happy to provide a minimal public reproduction (same pattern as our #8450 repro) if that would help — let us know.