fix(vite): keep re-exports in order when hoisting HMR imports - #11571

PR Checklist

• The PR title follows the commit guidelines.
• There is an issue for this bug.
• CLA status verified.
• All existing tests pass locally (see note below).
• Tests for the changes are included.

What is the current behavior?

Two /ns/m passes, hoistTopLevelStaticImports and ensureNativeScriptModuleBindings, move import declarations to the top of a served module but leave export ... from declarations in place. ESM evaluates module requests in source order, so this changes the order dependencies are evaluated in.

It breaks packages whose barrel re-exports modules before a side-effect import that leads back into the barrel. MasonKit's index.windows.js does:

export { Scroll } from './scroll';
export * from './web';
import './html-windows'; // imports ./web, which does `class BlockElement extends Scroll`

The served module starts with import ".../html-windows.js", so web.js evaluates before ./scroll, and the HMR boot fails with Cannot access 'Scroll' before initialization. Webpack and Vite's own transform keep the source order, so the app works in both.

What is the new behavior?

Both passes now move export ... from and export * from declarations along with the imports and keep their source order. Modules without re-exports are served exactly as before.

Adds regression tests for both passes. Each fails before the fix and passes after it.

Validation: on a Vue + MasonKit app (Windows target), I fetched the served /ns/m graph and simulated ESM evaluation order. Before the fix, web.js evaluates before scroll/index.windows.js; after it, scroll evaluates first. The full packages/vite vitest run on feat/windows passes except resolveFsAnchoredSpec returns the path actually found, which fails on that branch without this change too. Not yet verified with a device boot.

Related: triniwiz/nativescript-mason#163 removes the cycle on the MasonKit side.