fix: write registry allowScripts keys under install-strategy=linked - #10059

…9941)

Under `install-strategy=linked`, `npm install-scripts approve <pkg>`
wrote verbose, duplicated `file:` entries pointing into
`node_modules/.store` (one per incoming symlink depth) instead of
`name@version` pins, and those store-path entries never matched at
install time.

There are two root causes.
In `findNodesForArgs` (allow-scripts-cmd.js), positional args matched
every `Link` pointing at the store package; each Link's relative
`file:.store/...` resolved spec became its own policy key and could even
strip the correct pin as stale.
In `script-allowed.js`, a store package has no `edgesIn` (they land on
its incoming Links), so `isRegistryNode` refused registry keys, and
`ls`, the post-install advisory, and prune treated a correct
`name@version` entry as matching nothing.

The fix skips `Link` nodes when matching positional args, mirroring
`collectUnreviewedScripts` and prune, so approvals key off the real
package's trusted registry identity.
`isRegistryNode` and `nameFromEdges` now delegate edge-based checks to a
link target's incoming Links, which also covers
`omit-lockfile-registry-resolved` (approve by name, like the hoisted
#9558 path).
`resolvedSourceSpecs` no longer fabricates `file:` specs from links into
the store, so store packages are never keyed by store paths and prune
cleans up the buggy entries while keeping the valid pin.

## References

Fixes #9939

(cherry picked from commit b317f16)