fix: install pnpm deps in hoisted mode + declare @babel/types

[ZheSun88]

Summary

The Vite dev server intermittently fails (or hangs) on vite-basics and
other Vite-using IT modules because transitive npm dependencies are not
consistently reachable from the project's root node_modules. Selenium
tests then wait for pages that never render, and the matrix shard times
out at the 30-minute job cap.

Two distinct symptoms observed:

1. Cannot find package '@babel/types' — the bundled Vite plugin
   react-function-location-plugin.js does
   import * as t from '@babel/types';, but @babel/types was only
   present transitively via @babel/core and pnpm did not always hoist
   it to the root.

2. Failed to resolve import "@lit/reactive-element/...",
   "cookie", "set-cookie-parser", "@preact/signals-react/runtime" —
   all transitives of declared deps (lit, react-router,
   @preact/signals-react-transform) — also not consistently hoisted.

Both are the same underlying problem: pnpm with shamefully-hoist=true
does not deterministically expose every transitive at the project root.

Fix

Three commits, layered:

1. Declare @babel/types directly

Adds "@babel/types": "7.29.0" (matching @babel/core) to the bundled
devDependencies in
flow-server/.../dependencies/vite/package.json. Correct on its own
merits — the plugin imports the package, so the package should be a
real dependency. Updates NodeUpdaterTest's expected-set accordingly.

2. Switch the bundled .npmrc template to node-linker=hoisted

Adds node-linker=hoisted to flow-server/src/main/resources/npmrc,
the template TaskRunNpmInstall writes to the project. This tells
pnpm to install in flat npm-style mode — every package (declared
or transitive) at the project root, no .pnpm/ virtual store.
Resolutions become deterministic.

shamefully-hoist=true is left in the template alongside, so manual
pnpm install invocations from a developer shell still pick up at
least the legacy partial-hoist behavior if some user-level config
overrides our node-linker.

3. Pass --config.node-linker=hoisted on the pnpm CLI

The .npmrc change alone did not actually flip pnpm's install layout
in CI: node_modules/.pnpm/... paths kept appearing in error
messages, indicating pnpm was still using its default isolated
mode. The pre-existing --shamefully-hoist=true CLI flag added by
FrontendTools.getPnpmExecutable() likely took precedence and locked
pnpm to the isolated layout (where shamefully-hoist makes sense as
a partial-hoist heuristic).

Replace --shamefully-hoist=true with --config.node-linker=hoisted
on the CLI. CLI > .npmrc > defaults in pnpm's config precedence, so
the install is now unambiguously hoisted regardless of any project-
or user-level .npmrc content. FrontendToolsTest updated to assert
the new flag.

Trade-offs

• Disk/install time: hoisted mode uses slightly more disk and is
  a few seconds slower than the symlink store for fresh installs.
  Acceptable for the determinism gain.
• Loose isolation: hoisted mode allows packages to import any
  other package, declared or not. Flow's frontend code already relies
  on this (e.g. plugins importing transitives), so this is the
  current de-facto behavior — just made deterministic.
• Behavioral change for downstream users: anyone with a custom
  .npmrc that lacks the auto-gen marker keeps their config (per
  existing TaskRunNpmInstall.createNpmRcFile() logic), but the new
  CLI flag still applies — they'll silently get hoisted mode for
  Flow-driven installs. Worth flagging in release notes.

[github-actions]

Test Results

 1 404 files  ±0   1 404 suites  ±0   1h 21m 43s ⏱️ + 5m 51s
10 128 tests ±0  10 058 ✅ ±0  70 💤 ±0  0 ❌ ±0 
10 603 runs  ±0  10 524 ✅ ±0  79 💤 ±0  0 ❌ ±0 

Results for commit 8c4645e. ± Comparison against base commit a6c4ded.

♻️ This comment has been updated with latest results.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Artur-]

Looks like a good workaround but why do we need to add the same parameter to both npmrc and the command?

[Artur-]

Let's simplify in another PR - this unblocks everything else