fix(arborist): allow-remote exemption for proxy/mirror-fronted registry tarballs

[manzoorwanijk]

With allow-remote=none (the default on npm 12) or allow-remote=root, a npm install fails with EALLOWREMOTE on ordinary registry dependencies when the configured registry origin differs from the lockfile resolved origin.

npm error code EALLOWREMOTE
npm error Fetching packages of type "remote" have been disabled

This is the common proxy/mirror case: a committed package-lock.json whose resolved URLs point to https://registry.npmjs.org/..., while the machine (or CI) is configured to use a private registry proxy/mirror with a different origin.
It affects both the hoisted and the linked install strategy.

Why

When extracting a registry-resolved package, reify hands pacote a name@URL spec, which pacote re-parses as type=remote and gates with allow-remote.
To avoid mis-firing on registry tarballs, #isRegistryResolvedTarball exempts them — but it compared the raw lockfile resolved URL against the configured registry origin.
With a proxy/mirror configured, resolved is the canonical registry.npmjs.org URL while the configured registry is the proxy, so the origins never matched, the exemption returned false, and the registry tarball was rejected as remote.

Crucially, reify already fetches a different URL than the raw resolved: #registryResolved applies replace-registry-host (default npmjs), rewriting the registry.npmjs.org host to the configured registry while preserving the path.
So npm fetches the tarball from the proxy correctly; only the allow-remote check was evaluating the wrong (pre-rewrite) URL.

How

Evaluate the effective URL npm actually fetches, not the raw lockfile value.

#isRegistryResolvedTarball now parses this.#registryResolved(node.resolved) — the host-rewritten URL — before the same origin + registry-path-prefix comparison.
After rewriting, a public-registry-pinned tarball resolves to the configured registry and is correctly recognized as registry-mediated.

The existing security boundary is preserved: under the default replace-registry-host, a same-origin tarball pointing outside the registry path is not rewritten and is still rejected, and a genuinely URL-declared dependency still fails the node.isRegistryDependency guard.
Under replace-registry-host=always, every tarball is routed through the configured registry, so registry dependencies are no longer treated as remote — consistent with what always means.

References

Fixes #9548

[manzoorwanijk]

@owlstronaut @JamieMagee this change might require some careful review.