fix(ci): pin the npm wrapper lock refresh to npm@10 via npx

The release-readiness gate re-runs version-sync.sh and compares the
regenerated npm/socket-patch/package-lock.json byte-for-byte, so the
lock's canonical shape is defined by whatever npm regenerates it. npm 11
adds libc arrays that npm 10 omits, which is how the #233 refresh (made
locally with npm 11) broke the gate under CI's npm 10 — and the same
drift would recur in reverse the day the runner image jumps to npm 11.
Pinning the refresh via npx makes the gate independent of both the
runner default and the developer's local npm; bumping the pin now takes
a deliberate commit that refreshes the lock alongside it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: mikolalysenko

scripts/version-sync.sh

@@ -38,9 +38,17 @@ node -e "
 # Refresh the npm wrapper lockfile so package-lock.json stays in sync with the
 # bumped package.json (own version, optionalDependencies). Uses --package-lock-only
 # so node_modules is untouched.
+#
+# The npm major is pinned: the lock's byte shape depends on it (npm >= 11 adds
+# `libc` arrays to platform-package entries that npm 10 omits), and
+# release-lint.sh compares the regenerated lock byte-for-byte against the
+# committed one on every PR. An unpinned npm makes that gate depend on
+# whichever npm the runner or developer happens to have. Bumping this pin
+# requires refreshing the committed lock in the same commit.
+NPM_LOCK_REFRESH_VERSION="10"
 (
   cd "$REPO_ROOT/npm/socket-patch"
-  npm install --package-lock-only --ignore-scripts >/dev/null
+  npx --yes "npm@$NPM_LOCK_REFRESH_VERSION" install --package-lock-only --ignore-scripts >/dev/null
 )
 
 # Update all per-platform npm package versions