v1.4.1: Never follow symlinks when reading dependency files

@v1 points to this release, so if you use @v1 you already have it. If you pin a commit SHA, update it to this release. Every earlier version is affected.

Security fix

• Dependency files are now read from git, never from the checkout on disk. Earlier versions copied the PR's dependency file with cp, which follows symlinks. A PR could commit package-lock.json (or any scanned file) as a symlink to another file on the runner, and the action would upload that file's contents to npmscan.com instead of a lockfile. On a GitHub-hosted runner that could include the job's GITHUB_TOKEN (read-only on fork PRs, expires when the job ends). On self-hosted runners it could include any file the job can read.
• Both the base and PR versions now come from git cat-file, after git ls-tree confirms each is a regular file. A symlink or submodule is reported as a scan error and nothing is read or sent. A path under a symlinked directory is reported as not found.
• Thanks to @chenshuai2144 for reporting this in a review.

Worth knowing

• The scan now covers exactly what the PR commits. If an earlier step in your workflow edits a dependency file after checkout, those edits are no longer scanned.
• A symlinked dependency file shows as an error in the report. It fails the check only with fail-on-error: true.

Tested on

• New tests: a lockfile swapped for a symlink to a fake secret (no request is made), a symlink on the base branch, a file under a symlinked directory, and uncommitted edits after checkout. All 4 fail on v1.4.0 and pass now, on Ubuntu and macOS.

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