Repair scheduled Snyk workflow lockfile resolution and SARIF upload

[Copilot]

The scheduled Snyk Security Scan workflow was failing in the security job for two separate reasons: Snyk resolved a workspace dependency against the wrong lockfile, and the SARIF upload step still used a deprecated CodeQL action while assuming snyk.sarif always existed.

• Scope the Snyk scan to the root npm lockfile

  • Run Snyk against package-lock.json explicitly instead of relying on auto-detection in a workspace repo.
  • Emit SARIF directly from the scan so the upload step consumes the same result set.

  - name: Run Snyk scan
    id: snyk
    uses: snyk/actions/node@v1.0.0
    continue-on-error: true
    with:
      args: --file=package-lock.json --package-manager=npm --severity-threshold=high --sarif-file-output=snyk.sarif

• Make SARIF upload resilient

  • Upgrade github/codeql-action/upload-sarif from v2 to v3.
  • Upload only when snyk.sarif exists, avoiding a second failure mode when the scan exits before producing output.

• Preserve workflow failure semantics

  • Keep continue-on-error on the Snyk step so SARIF upload can still run.
  • Re-fail the job afterward when the Snyk scan itself failed, so the workflow still surfaces real security findings/errors.

• Align workflow actions with current repo usage

  • Update actions/checkout and actions/setup-node from v3 to v4.
  • Pin snyk/actions/node to a stable release instead of @master.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.