fix(vite): scan top-level imports with Vite's native parser - #11634

What

The /ns/m dev route parses each served module with Babel several times just to find its top-level imports (collectTopLevelImportRecords in two places, plus the dev default-import link check). On modules whose code sits on a few very long lines, Babel's skipBlockComment becomes quadratic: for every block comment it runs lineBreakG.test(this.input) from the comment start to the next line break anywhere in the input, not just to the comment's end.

Real case: a 3.9 MB dependency chunk (shaders/dist/core/std-*.js) is transformed by Vite's dev pipeline into 225 lines, the longest 1.9 MB with about 2,000 block comments. One Babel parse of that output takes ~1.5 s (0.26 s on the original multi-line file), and a single cold request did about six of them. CPU profiles showed @babel/parser at 8.7 s of an 11.25 s request, 7.2 s of it in skipBlockComment. Because this runs synchronously, the dev server's event loop is blocked for the whole request, and the iOS runtime's module loader timed out during cold boot (NSURLErrorDomain -1001) before the app could start.

How

• New parseTopLevelStatements(code) in websocket-served-module-helpers.ts returns top-level statements from Vite's parseAst(code, { lang: 'tsx' }) (Oxc), or null if Oxc rejects the code.
• Both collectTopLevelImportRecords implementations use it first and fall back to the unchanged Babel parse. If both fail, they still return []. Node checks are plain type comparisons that work on either AST. Output fields are unchanged.
• New collectStaticImportDefaultIntents(code) replaces the link check's inline parse and traverse. Static imports can only appear at top level, so scanning top-level ImportDeclarations is equivalent. It falls back to the previous Babel parse and traverse, and still throws on a double failure, so the caller's try/catch behaves as before.
• Other Babel uses (astExtractImportsAndStripTypes, collectReExportAndDynamicImportSources, the normalizer) are untouched.

vite is already a dependency of @nativescript/vite (^8.0.0), so no new dependency.

Test plan

• npx vitest run hmr/server/websocket-served-module-helpers.spec.ts hmr/server/websocket-import-records-fallback.spec.ts: 26 pass. Covers default, named and string-named specifiers, exact text slices after non-ASCII text, import type, TS+JSX input, no imports, a forced Oxc failure falling back to Babel, ensureNativeScriptModuleBindings on both paths, and default-import intents.
• Long-line regression: one import plus a single line with 12,000 block comments. Babel-only took 10.3 s on this machine; the new path takes about 0.05 s. The spec asserts under 2 s.
• npx nx run vite:build. Touched files are lint-clean; vite:lint still reports 3 existing errors in untouched files (configuration/base.ts, css-device-module.ts).
• Applied as a patch to published 8.0.20 and 8.0.21 in a large app. A cold request for the module above went from 11–21 s to 5–9 s on a heavily loaded host (load average 40–190); the rest is untouched Babel work and the Vite transform. The @babel/parser share dropped from 8.7 s to 1.2 s. A serial cold crawl of the app's 1,443-module boot graph went from 241.6 s to 108.9 s, with the slowest module dropping from 4.9 s to 1.4 s.
• The same app now completes an iOS simulator HMR cycle from a cold dev server: launch, an in-place JS edit on the same process, and a native edit with rebuild and relaunch. Before this change it failed during module loading.