Prevent cache poisoning vuln in GitHub Actions sample workflows

[generalmimon]

The PR #1917 bumped the actions/setup-node action from v4 to v6. This made the publishing GitHub Actions sample workflows potentially vulnerable to cache poisoning, because v5 and later enable caching by default (see https://github.com/actions/setup-node/blob/53b83947a5a98c8d113130e565377fae1a50d02f/README.md#breaking-changes-in-v5). v6 only enables automatic caching if the packageManager field in package.json is set to npm.

Consuming GitHub Actions cache in publishing workflows is discouraged, because the cache may be poisoned by compromising any low-privileged workflow in the same repository. Normally, a code injection vulnerability in a low-privileged workflow (for example permissions: {contents: read} and no secrets) is not a big deal, because the attacker cannot do much more than poison the repository cache (which requires no permissions). If caching is only used in other low-privileged workflows, the impact is limited. However, if a high-privileged workflow like the release build consumes the cache, then it becomes a real problem.

As @AdnaneKhan concludes in his blog posts about GitHub Actions cache poisoning, such as
https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning/#dont-use-actions-caching-in-release-builds: "the best way to protect the integrity of releases is to avoid using GitHub Actions caching entirely for release workflows."

The README of actions/setup-node also recommends package-manager-cache: false for privileged workflows (see https://github.com/actions/setup-node/blob/53b83947a5a98c8d113130e565377fae1a50d02f/README.md#breaking-changes-in-v5):

For workflows with elevated privileges or access to sensitive information, we recommend disabling automatic caching by setting package-manager-cache: false when caching is not needed for secure operation.

References

Related to #1917