ci: live-registry smoke test fails on a socket reset with fetch retries disabled

Summary

The ordinary CI Smoke Tests job on latest fails when the live-registry, low-memory installation scenario receives a socket reset. The smoke harness disables fetch retries, so the reset immediately fails the job.

This issue tracks one network-sensitive test incident and its missing root-cause evidence. The logs do not establish whether the socket reset originated in npm's client, the runner/network, or the registry.

Affected run

Branch: latest, commit c039090578a5b21a1aa3aba9c96e199feaf1823a, npm 12.1.0, Node v26.10.0.

Workflow: https://github.com/npm/cli/actions/runs/35779327465

Failing job: Smoke Tests

Failing scenario: smoke-tests/test/large-install.js, large install, no lock and low memory.

The other 22 jobs in this CI run passed.

Failure

npm error code ECONNRESET
npm error errno ECONNRESET
npm error network request to {REGISTRY}/@popperjs/core/-/core-2.11.8.tgz failed, reason: socket hang up

The logged command explicitly contains:

--fetch-retries=0

The process exits with code 1 and no signal. This is not an out-of-memory diagnostic despite the scenario's low-memory setting.

Confirmed mechanism and uncertainty

The scenario deliberately uses the production registry, omits the lockfile, and constrains the V8 heap to 500 MB. The shared harness adds --fetch-retries=0, including for this non-mocked test.

The immediate failure is a tarball-request connection reset with no retry. The initiating cause of that reset is unresolved. Do not label it a confirmed registry outage, an npm regression, or a harmless transient without additional evidence.

The test's own comments link #6763 and #7072 and explain that earlier flakes might reveal a maxSockets bug. That context must be preserved when deciding whether to change retry behavior.

Investigation and resolution

• Correlate repetitions with runtime, runner, concurrency, socket limits, and fetch timing to distinguish an infrastructure interruption from a client regression.
• Decide whether zero retries is intentional for this real-network scenario. If bounded retries are appropriate, scope them to the live-registry case and retain useful diagnostics rather than weakening all mocked smoke tests.
• Preserve coverage for large installs and constrained memory.

Acceptance criteria

• The issue records the best-supported cause or explicitly retains the remaining uncertainty.
• Any retry or concurrency change has a documented rationale that accounts for #6763 and #7072.
• The scenario completes on supported runtimes without concealing a reproducible socket-management regression.

Scope boundary

This is ordinary CI, not the Release Integration nightly download in #10016 or the stale archive URL in #10020. It is also different from the npm 12 Node 23 engine failures: this run uses supported Node 26.