feat(vite): support node integration in renderers

[tzh476]

Closes #3961.

This follows up on #4258 and keeps its renderer-level nodeIntegration API. @rafael81 is retained as a co-author.

Why externalization is not enough

While validating #4258 in Electron, I found that externalizing Electron and Node.js built-ins leaves bare ESM imports in the renderer output. Vite loads that output as a browser module, which fails before application code runs:

Uncaught TypeError: Failed to resolve module specifier "electron".
Relative references must start with either "/", "./", or "../".

The development server similarly resolves Node.js modules to Vite browser-external stubs.

What changed

• add an opt-in renderer[].nodeIntegration setting
• load Electron and Node.js built-ins through runtime ESM shims in both serve and build modes
• support default, named, namespace, side-effect, and dynamic imports
• keep built-ins out of Vite dependency optimization and CommonJS conversion
• disable Rollup namespace freezing so CommonJS packages such as fs-extra can augment Node.js modules
• merge these settings with existing user Vite and Rollup configuration
• document the required Electron preferences and security implications

The runtime-shim approach follows the model proven by
vite-plugin-electron-renderer,
implemented here only for built-ins so Forge does not gain another runtime
dependency.

Security boundary

This option only configures Vite. The corresponding BrowserWindow must use nodeIntegration: true and contextIsolation: false. It should only load trusted local content; a preload script with contextBridge remains the safer default.

Validation

$ yarn vitest run --project fast packages/plugin/vite/spec
Test Files  4 passed (4)
Tests       19 passed (19)

$ yarn tsc -b packages/plugin/vite --force
# passed

$ yarn eslint packages/plugin/vite/spec/ViteConfig.spec.ts packages/plugin/vite/spec/config/vite.node-integration.config.spec.ts packages/plugin/vite/src/Config.ts packages/plugin/vite/src/config/vite.node-integration.config.ts packages/plugin/vite/src/config/vite.renderer.config.ts
# passed

$ yarn electron-markdownlint packages/plugin/vite/README.md
# passed

I also ran an Electron 39.2.6 / Vite 6.4.3 smoke fixture against the compiled Forge plugin in both development-server and production-build modes. It exercised default, named, namespace, side-effect, and dynamic built-in imports plus a transitive fs-extra CommonJS dependency; both modes delivered the expected IPC result.

---

If next is the right base for this, a rebased branch is ready:
tzh476:feat/vite-node-integration-next
— the same change re-applied onto a fresh copy of next (1 commit ahead, 0 behind, the same 6 files).

I noticed every recently merged feat* PR targets next rather than main, so this may be aimed at the
wrong branch. Rather than change the base ref here — which caused unrelated diff churn on #4168 — I
re-applied the commits onto next, which is what was asked for there. Two things needed adapting:
vite.renderer.config.ts keeps next's ./vite.base.config.js import convention, and the README keeps
both the existing "Main process hot restart" section and the new one.

Say the word and I will open it as a PR, or close this one in its favour — whichever you prefer. Happy to
leave it on main too if that is correct.

[tzh476]

Verification for this PR, since it has been open a while with no CI run — posting evidence rather
than a ping.

Tests pass, and they are real controls. I ran the plugin's suite locally and then mutation-tested
it, because a test that cannot fail proves nothing:

yarn vitest run --project fast packages/plugin/vite
  10 passed

mutant	result
remove pluginNodeIntegration() from vite.renderer.config.ts	killed — wiring test fails
make the plugin's resolveId always return undefined (shims never resolve)	killed — 2 of 3 node-integration tests fail

Worth flagging honestly: the first mutant is caught by only one test — 6 of 7 still passed with
the plugin unwired, because most specs exercise the plugin directly rather than through the
renderer config. If a maintainer wants a tighter net there, that is a fair review point and I am
happy to add coverage.

One failure I want to attribute correctly: spec/VitePlugin.spec.ts errors with
Failed to resolve entry for package "@electron-forge/plugin-base". That is not from this
branch — it fails identically on main in my workspace, because I installed with
--mode=skip-build so the workspace packages were never compiled. Same command, same environment,
main and this branch both fail it. I am not claiming a fully green suite.

On the CI status. Three github-actions check-suites on head 688e4db6 sit at
action_required with latest_check_runs_count = 0 — the test workflows have never run, which I
believe is the standard first-time-contributor approval gate rather than anything failing. Nothing
here is fixable from my side; it needs a maintainer to approve the run.

Relationship to #4258. That PR (@rafael81) came first and this one builds on it — it keeps the
renderer-level API and retains @rafael81 as co-author. The difference is runtime behaviour:
externalizing Electron/Node builtins alone leaves bare ESM specifiers in the renderer output, so
Electron throws Uncaught TypeError: Failed to resolve module specifier "electron" before app code
runs. This adds virtual-module ESM shims for builtins only, with no new runtime dependency. I am
not asking anyone to prefer this over #4258 — whichever lands, the feature request in #3961 gets
resolved.

Happy to rebase, split anything out, or adjust the approach on request.