v1.3.0: Known malware and swapped tarballs always caught

@v1 points to this release, so existing workflows get it automatically. No changes needed.

Stricter

• Known malware always blocks. A package version with a malicious-package advisory (an OSV MAL- record, or a GitHub advisory for embedded malicious code) now fails the check in mode: block whatever fail-on-severity says. These advisories are often rated only HIGH, so fail-on-severity: critical used to let a release like ua-parser-js 0.7.29 through. Malware is labelled ☠️ in the table, the advisory list and the line annotation. Only mode: warn stops it blocking.
• Swapped tarballs are caught. A lockfile entry whose tarball is a different package or version than it declares (e.g. left-pad@1.3.0 pointing at minimist-0.0.8.tgz) now counts as a source change, and the comment names the real tarball. Before, a newly added entry like this only showed up as a vulnerability of the declared package. It's controlled by fail-on-source-change, like other source changes.

Fewer false alarms

• A dependency's prepare script no longer counts as a new install script. npm never runs a dependency's prepare when installing it from the registry, so a bump like husky 6 → 7 is no longer blocked for it. This changed on the npmscan.com side and already applies to every version of the action. Your own root prepare script is still flagged, because it does run on npm install in your repository.

Tested on

Two new tests replay real npmscan.com API responses for a malware release and a swapped tarball, alongside the existing npm, pnpm, Yarn classic/Berry, monorepo, fork-PR and outage tests (119 assertions).

📖 Full docs: https://npmscan.com/docs/github-action