fix(ci): use current actions, so the release cache step stops failing

[sasjs-dev]

What

actions/setup-node@v2 with cache: npm calls the legacy cache API, which GitHub has sunset. It answers 400, and the step fails before the build or semantic-release is reached:

##[error]Cache service responded with 400

That is the whole of the release failure on main since the engines change merged. It is reproducible rather than transient - it failed identically on the first run and on the re-run - and it means nothing has been published from this repo since.

actions/checkout and actions/setup-node move to @v4 in both workflows, which use the current cache API. build.yml carries no cache: and so did not trip the 400, but it was on the same deprecated majors.

Verification

• both workflow files parse as YAML
• the only steps touched are checkout and setup-node; nothing else in either workflow moved

Not changed here, but worth a look

npmpublish.yml still releases through cycjimmy/semantic-release-action@v2 with secrets.NPM_TOKEN. The rest of the estate moved to running semantic-release directly from the locked release/ tree with the npm trusted publisher, which is what removes the long-lived publish token. That is a larger change than a version bump and belongs in its own PR - flagging it because this repo is now the outlier.

[sasjs-dev]

Reviewed the full base...head diff (two workflows, checkout@v2 -> v4 and setup-node@v2 -> v4 in build.yml:21-25 and npmpublish.yml:23-26). The fix itself is correct and targeted - setup-node@v2's cache: npm hits the sunset legacy cache API, which is what has been failing the release job, and v4 uses the current API. The PR builds are green at head on both matrices. Findings on the state the release path is left in:

• .github/workflows/npmpublish.yml:23 - checkout runs with the default fetch-depth: 1 (shallow). semantic-release needs full history and tags to compute the release; its own GitHub Actions recipe (semantic-release/docs/recipes/ci-configurations/github-actions.md) pins actions/checkout with fetch-depth: 0. The repo has not cut a release since 1.5.7 in October 2022, and nothing in this PR unblocks that beyond the cache 400 - a release that does fire will read a truncated history and either cut from the wrong baseline or fail. Add with: fetch-depth: 0 to the release job's checkout.

• .github/workflows/npmpublish.yml:38 - the release job uses cycjimmy/semantic-release-action@v2, whose semantic-release range is pinned to a v17-era release; the repo's own package.json declares engines node >= 22. Verify the action's resolved semantic-release supports the Node floor, or bump the action major (current is v6) while this file is open - otherwise the first successful release run can fail on the toolchain rather than the code.

• no .pre-commit-config.yaml anywhere in the repo, so no gitleaks secret-scan hook at commit time (standing all-repo requirement). Add one with the gitleaks hook pinned to an exact release tag (v8.30.1 shape: repo: https://github.com/gitleaks/gitleaks, rev: vX.Y.Z, hooks: - id: gitleaks).

• no npm audit step in either workflow - a PR that ships a dependency with a known advisory currently merges green. build.yml already runs npm ci before the build; add a strict audit step (npm audit --audit-level=low, or --omit=dev to scope to production dependencies) alongside it so the gate fails the build. package.json is also all-range (^ everywhere except two exact pins), including peerDependencies; committing .npmrc with ignore-scripts=true and save-exact=true stops the drift recurring at install time.

4 findings above for review.