fix: prefer system npm/npx over project-local versions from node_modules

[mtorp]

Summary

• When the CLI runs inside an npm script (or any context where node_modules/.bin is on PATH), getNpxBinPath() could pick up a project-local npx instead of the system one
• The standalone npx package (npx@10.2.2) bundles npm@5.1.0 which is incompatible with Node 22+, causing cb.apply is not a function errors during Coana reachability analysis
• Fix: check for npm/npx next to process.execPath before falling back to PATH-based lookup, following the same pattern already used by findRealNpm() in @socketsecurity/registry and getAgentExecPath() in package-environment.mts

Test plan

• TypeScript type check passes
• Lint passes (0 errors)
• All 871 unit tests pass (pre-commit hook)
• Manual test: install npx@10.2.2 in a project, run scan with reachability from an npm script — should no longer crash

🤖 Generated with Claude Code

---

Note

Medium Risk
Medium risk because it changes how the CLI locates and executes npm/npx, which can affect behavior across environments (especially Windows and custom Node installs), though the change is narrowly scoped to path resolution.

Overview
Ensures the CLI prefers system npm/npx over project-local versions that may appear on PATH (e.g. from node_modules/.bin) by first probing for binaries next to process.execPath.

Adds findBinNextToNode() (with symlink resolution via resolveBinPathSync) and uses it in getNpmBinPathDetails()/getNpxBinPathDetails() before falling back to the existing PATH-based lookup, reducing failures from incompatible bundled npm/npx versions on newer Node runtimes.

^{Reviewed by Cursor Bugbot for commit 7a6441d. Configure here.}