fix(plugin-vite): declare vite as a peer dependency

[tifandotme]

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project follows, as appropriate.
• The changes are appropriately documented (if applicable).
• The changes have sufficient test coverage (if applicable).
• The testsuite passes successfully on my local machine (if applicable).

Summarize your changes:

Fixes #4350.

@electron-forge/plugin-vite requires Vite at runtime from dist/VitePlugin.js, dist/ViteConfig.js and the three dist/config/vite.*.config.js files, but declares it only in devDependencies. A hoisted node_modules resolves this by accident, through the application's own copy of Vite. A strict layout does not resolve it at all, so the plugin cannot be loaded and electron-forge start and electron-forge package both fail. The issue has a Bun 1.4 reproduction. pnpm and Yarn PnP fail for the same reason.

Why a peer dependency and not a regular one

plugin-webpack declares webpack as a regular dependency, but Vite is not the same case. Webpack is an implementation detail of that plugin. Vite is chosen by the application: the user writes vite.main.config.ts and picks the major version, and Forge reads that file with loadConfigFromFile from whichever Vite it resolves. A pinned regular dependency would install a second Vite and parse the user's config with the wrong major. A peer dependency keeps one Vite in the tree.

Range

>=5 matches what the package supports in practice: 7.11.2 shipped against vite@^5, main builds against ^6, and applications on ^7 and ^8 work today. Happy to narrow it to an explicit list if you prefer.

Repository constraints

No constraint churn. enforceConsistentDependenciesAcrossTheProject in yarn.config.cjs skips peerDependencies and already exempts vite by name. vite stays in devDependencies for the package's own tests. yarn.lock picks up the two-line peer entry for the workspace.

Tests

None added. The change is package metadata with no code path to assert on, and the regression it prevents is only observable from a real install under a strict linker.