fix: validate registry path for allow-remote tarball exception

[Abhinav-143x]

Summary

Tighten the registry-mediated tarball exception used when extracting registry dependencies under allow-remote.

Previously Arborist treated a resolved tarball as registry-mediated when its hostname matched the selected registry hostname. That allowed same-host sibling paths to bypass allow-remote=none for path-qualified registries, for example:

• registry: https://registry.example.com/npm/
• resolved tarball: https://registry.example.com/evil/pkg-1.0.0.tgz

This change requires the resolved tarball URL to match the registry origin and remain under the selected registry path before overriding pacote's allowRemote handling.

This is a tightening of the registry tarball exception introduced around #9348, and is related to the allow-remote=none behavior discussed in #9347, but covers the path-qualified registry case.

For root-scoped registries, origin match remains sufficient because there is no registry path boundary to enforce.

Testing

• node node_modules/tap/bin/run.js test/lib/commands/ci.js --no-coverage
• node node_modules/tap/bin/run.js test/lib/commands/install.js --no-coverage

[Abhinav-143x]

Opened companion issue #9474 to track the path-qualified registry boundary behavior. This PR is the proposed fix for that issue.

[Abhinav-143x]

Pushed a follow-up in 1b25357 to cover the Arborist registry-path allow-remote cases and simplify the registry path normalization branch. The previous Arborist CI failure was coverage on reify.js; locally the focused reify coverage is now 100%, and the new GitHub workflow runs are currently waiting on action_required approval for the forked PR.

[Abhinav-143x]

CI is green now. @owlstronaut, it would be kind of you to review this when you have cycles.

[github-actions]

🎉 Backport to release/v11 created: #9489