Fuzzer and lint_fuzzer_sanity tasks fail with:

npm ERR! code E503
npm ERR! 503 Service Temporarily Unavailable - GET
https://artifactory.corp.mongodb.com/artifactory/api/npm/npm/eslint
subprocess.CalledProcessError: Command 'npm install' returned non-zero exit status 1

jstestfuzz's src/scripts/npm_run.py runs `npm install` on a fresh clone. We have migrated npm to the public npmjs registry, but some Evergreen distro images still carry a global npm config pointing at artifactory.corp.mongodb.com, whose npm proxy returns 503s. Nothing in mongo or jstestfuzz sets `registry` – jstestfuzz has no .npmrc, mongo's is just `hoist=false`, and npm_run.sh sets only npm_config_cache – so resolution silently depends on which distro a task lands on.

Observed on mongodb-mongo-v7.0-staging / enterprise-amazon2023, task query_fuzzer_plan_cache_0 on 2026-08-05 06:22-06:56Z: five install attempts, each 503ing on the same URL, exhausting npm_run.py's retry loop. The same task is green on master's enterprise-amazon-linux2023-arm64 with an identical jstestfuzz tree, so the distro's npm config is the only variable.

The install needs the registry at all – despite jstestfuzz having a complete, exactly pinned, artifactory-free package-lock.json (lockfileVersion 2, 670 entries, zero range specs) – because its peer dependencies conflict: @typescript-eslint/utils@5.62.0 (transitive, via gts) and eslint-config-prettier@10.1.5 clash with the root's eslint@9.31.0. npm reports ERESOLVE and re-resolves the tree, which requires a package-metadata request (`GET <registry>/eslint`, no version) that the lockfile cannot satisfy.

Export npm_config_registry from a shared jstestfuzz_npm_env.sh, sourced by the four entry points that can trigger a cold `npm install`. Also set npm_config_fetch_retries so npm rides out transient blips itself, in addition to npm_run.py's coarse whole-install retry loop.

Scoped to a sourced helper rather than prelude.sh on purpose: a global export would also redirect mongo's own pnpm lint dependencies, a far wider blast radius than this bug warrants.

This is not reachable by a SERVER-132763style `-jstestfuzzGitRev` bump. That fixed only the 'resolved' tarball URLs; query_fuzzer_plan_cache pins no rev on any branch, including master, and the failing v7.0 runs were already on 101ae461, the rev master pins. Two better long-term fixes exist, both outside this repo: re-image the lagging distros, or fix jstestfuzz's peer ranges so npm can build the tree from the lockfile and drop the registry from the hot path.

Anything in this description will be included in the commit message. Replace or delete this text
before merging. Add links to testing in the comments of the PR.