Clear the npm advisories, move Actions to Node 24, and fix the CLI version check

[blackoutjack]

Clears every remaining npm advisory, including the three whose only fix was a semver major and were held back from the v1.0.7 dependency pass, moves the GitHub Actions off the deprecated Node 20 runtime, and fixes a version check that told users their CLI was out of date when it was newer than the floor the plugin builds against. npm audit now reports nothing at any severity, and this supersedes all seven open Dependabot PRs (#134, #138, #139, #148, #150, #159, and #149, whose package websocket-driver is no longer in the tree at all).

Implementation

• Move GitHub Actions off the deprecated Node 20 runtime: actions/checkout and actions/setup-node to v7, release-drafter to v7.7.0, all on node24 (NV-4884).
• Clear the uuid and webpack-dev-server advisories: uuid 9 to 14 and webpack-dev-server 5 to 6; @types/uuid removed, since uuid has shipped its own types since v10.
• Upgrade react-router to 7 to close its last two advisories: the open redirect via backslash in Link and useNavigate, and constructor injection in deserializeErrors().
• Stop reporting a newer CLI as outdated: isCliOutdated never stopped at the segment that settles the comparison, so any segment below the floor's raised the update prompt; ports the three-way compareCliVersions the IntelliJ plugin already uses (NV-4897).
• Record 1.0.7 and 1.0.8 in the changelog: v1.0.7 tagged and shipped with no entry at all, since the version bump is automated and the changelog is not; the file ships in the .vsix and is what the Marketplace Changelog tab renders.

Out-of-scope

• No Jira commit sync here, unlike the sibling repos. A public repository cannot call a reusable workflow stored in an internal one, so the callers were removed from this branch; see NV-4883.
• The CLI version floor itself is unchanged at 0.15.0. Raising it is what masked the comparison bug (NV-4872), and the next raise to a version with a non-zero patch would have exposed it again.

Verification

make test passes, but it covers only the extension host: nothing in the suite renders the webview, so neither the react-router nor the uuid upgrade is exercised by it. Both were checked by loading the built dist/webview.js in a browser against a stub of the extension-host message channel, and then re-running the identical harness against a bundle built from main. The two behave the same: the app boots, createMemoryRouter and the MainLayout Outlet render, Link navigation between routes works, uuid produces valid v4 request ids, and the only console errors are the same pair the stub provokes on both bundles.

The react-router 7 upgrade was also checked against the webview's actual API surface rather than assumed safe. It uses only the element-based router (createMemoryRouter with path, element, errorElement, children, plus Link, Outlet, useNavigate, useParams), with no loaders, actions, fetchers or Form, so none of the v7 future flags that became default behaviour apply and none of the removed helpers are referenced.

The webpack-dev-server 6 upgrade is not covered by make test either, which never starts the dev server, and it is what forced the ProvidePlugin change. v6 ships as "type": "module", so its client is fully specified ESM; fully specified resolution ignores resolve.extensions entirely, so the bare process/browser specifier could not resolve from it and the dev server compiled with two errors until the plugin was given a resolved path. v5 was CommonJS, which is why this surfaced only on the upgrade. Checked by hand afterwards: the dev server compiles clean, serves webview.js over HTTP 200, and returns the expected CORS header.

react-router 7 hits the same resolution rule from .mjs rather than a second one, which widens the consequence: reverting to the bare specifier was tried in both configurations, and with react-router 6 only the dev server fails while a production build still passes, whereas at HEAD a plain production build fails on its own. The config comment names both dependencies so that dropping either does not read as licence to revert it.

The version-check fix is dated against the CLI's own release tags rather than argued from examples. Replaying all 182 released versions through the old comparison puts 20 of them on the wrong side while the floor was 0.9.5: every release from 0.10.0 onward whose patch was below 5, up to and including 0.16.1. Under the current 0.15.0 floor none of the 182 are misjudged, so the bug is masked rather than absent on main, and either a 1.x release or a floor carrying a non-zero patch restores it. Each of the eight isCliOutdated assertions added here fails against the previous implementation, and the five compareCliVersions cases could not run against it at all.