chore(ci): setup dependency firewall for npm

[staaldraad]

What kind of change does this PR introduce?

CI hardening.

When publishing, ensure dependencies are pulled in via the dependency firewall.

• DF_FIREWALL_TOKEN value set
• Policy in evaluation mode for teting

[coveralls]

Coverage Report for CI Build 31712468053

Coverage remained the same at 81.054%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	12891
Covered Lines:	10873
Line Coverage:	84.35%
Relevant Branches:	7683
Covered Branches:	5803
Branch Coverage:	75.53%
Branches in Coverage %:	Yes
Coverage Strength:	522.91 hits per line

---

💛 - Coveralls

[claude]

LGTM — straightforward CI hardening change.

Extended reasoning...

Overview

This PR adds an opt-in npm dependency firewall (DepthFirst) to the CI node setup actions and wires the auth token secret only into the release.yml publish workflow. It touches three files: two composite actions (setup-node-dependencies, setup-node-npm) and release.yml.

Security risks

The main risk to check was whether DF_FIREWALL_TOKEN could leak to untrusted code, since it is only safe to use in workflows that never run on pull_request (per the action's own input description). I verified that ci.yml and acceptance.yml (both triggered on pull_request) call setup-node-dependencies/setup-node-npm without passing firewall-token, so it defaults to an empty string and the firewall-configuration step (if: inputs.firewall-token != '') is skipped there. Only release.yml, which triggers on push to master and workflow_dispatch, passes the secret. The token is injected via an env: var and referenced with `` inside the script rather than interpolated directly into the YAML, avoiding shell/script injection from untrusted branch content.

Level of scrutiny

This is CI-only configuration with no production code paths touched, but it does handle a secret token, so I checked its blast radius carefully (see above) rather than treating it as a pure mechanical change. The docker image publish path does not receive the firewall config, which was already flagged and ruled out by the bug hunt as out of scope for this npm-focused change.

Other factors

The change is small, additive (new optional input defaulting to a no-op), and does not alter existing behavior for any workflow that doesn't explicitly pass the token. No tests are affected since this is pure CI plumbing.