fix: recognize allowScripts for local link targets

[cyphercodes]

Summary

• Recognize local directory link targets by their incoming link source when matching allowScripts policy entries.
• Reuse that source identity when approve-scripts/deny-scripts derive file dependency policy keys.
• Add coverage for reviewed local file: dependency link targets.

Fixes #9488

Testing

• node node_modules/tap/bin/run.js --no-coverage workspaces/arborist/test/script-allowed.js workspaces/arborist/test/unreviewed-scripts.js test/lib/utils/allow-scripts-writer.js test/lib/utils/check-allow-scripts.js test/lib/utils/resolve-allow-scripts.js
• node node_modules/eslint/bin/eslint.js lib/utils/allow-scripts-writer.js test/lib/utils/allow-scripts-writer.js workspaces/arborist/lib/script-allowed.js workspaces/arborist/test/script-allowed.js workspaces/arborist/test/unreviewed-scripts.js
• git diff --check
• Manual repro: local file: dependency with allowScripts: { "file:../testdep": false } no longer emits an allow-scripts warning; npm approve-scripts --all writes file:../testdep.

[owlstronaut]

@JamieMagee So this looks valid to me for v11, if the user has added file: as an approve script we shouldn't warn.

One thing I'd like your read on for v12 before this lands there: in rebuild.js the scriptsAllowed check short-circuits on node.isLink, with the comment "Bypasses: --dangerously-allow-all-scripts, links and workspaces (the owner is responsible)." I confirmed that means "file:../dep": false doesn't actually block the script, it runs in all cases (true, false, absent) on latest. Before this PR you'd at least see a warning. With it merged the warning is gone too, so the user gets total silence on top of a script that still runs. Is the isLink bypass the intended v12 behavior (file: deps treated like workspaces, owner-managed, allowScripts entries are warning-control only), or a gap that should be closed before v12 ships?

[owlstronaut]

This adds node.realpath and node.path to the spec list for every node. A registry-resolved package can't match a file policy key because matchFileOrDir short circuits. With this change a registry package like sharp@0.33.0 installed at proj/node_modules/sharp will match a k ey like file:/proj/node_modules/sharp": true.

[JamieMagee]

+1 to @owlstronaut. The guard on line 113 is always true since linksIn is always a Set, so these two lines add realpath/path for every node, not just link targets. A registry package's install path then becomes a match candidate for file:/directory keys. I checked locally: a registry node returns true for {"file:node_modules/<name>": true} where base returns null.

Can we gate the paths on the real link-target case, e.g. only add them when !node.resolved && node.linksIn.size > 0?

[JamieMagee]

The same root cause leaks into the writer. If a link target has an empty linksIn (so resolved is null), resolvedSourceSpecs(node)[0] is node.realpath, an absolute path. versionedKeyFor/nameKeyFor then take the startsWith('/') branch and write something like /proj/node_modules/A into allowScripts instead of file:../A. Better to prefer a file: candidate over a bare path, or return null so we don't persist a machine-specific key. Fixing comment 1 with the size > 0 guard mostly covers this too.

[JamieMagee]

Could you add a negative case here? A registry node (resolved = tarball URL, empty linksIn) shouldn't match a file: key by its install path: t.equal(isScriptAllowed(reg, { 'file:node_modules/<name>': true }), null). That pins down the boundary @owlstronaut flagged. Covering an empty linksIn Set and a link with resolved === null would help too.