fix: use a clean install when generating the SBOM for the npm-ci builder

[AliAltivate]

Description

Fixes #1197.

GetModuleSBomGenCommands groups npm, npm-ci, grunt and evo into one switch case and runs npm install for all of them. For a module built with the npm-ci builder, the build itself installs strictly from package-lock.json, so resolving dependencies afresh just to generate the SBOM can record versions that are not the ones actually shipped. That is what the reporter hit: an SBOM listing dependencies they do not ship, which fails their SLC-41 SBOM upload.

This makes the npm-ci builder use npm clean-install for SBOM generation. npm, grunt and evo keep npm install exactly as before.

On the spelling: npm clean-install is an alias of npm ci. I used clean-install because that is the spelling already in configs/builder_type_cfg.yaml for this builder (npm clean-install --production), so the SBOM path and the build path now read the same. Happy to switch it to npm ci if you prefer the shorter form.

On --production: deliberately not added. The build path uses --production to ship a lean artifact; the SBOM path has always installed everything, and dropping devDependencies would change which components appear in the SBOM. That is a different behavioural change from what this issue asks for, so only install-vs-clean-install changes here.

Left alone on purpose: the other npm install in this function, in the custom builder fallback for nodejs modules (currently line 386). A custom builder is a black box and may not use a lock file at all — and npm clean-install hard-fails when package-lock.json is absent — so assuming a clean install there would risk breaking working builds. Say the word if you'd like it changed too and I'll follow up.

Tests

Two It blocks added to the existing Describe("GetModuleSBomGenCommands", ...):

• the npm-ci builder emits npm clean-install as its first command, followed by the unchanged npx @cyclonedx/cyclonedx-npm ... command;
• the npm builder still emits npm install — a regression guard so a future refactor can't silently swap the two.

I checked that they actually pin the behaviour rather than just passing: reverting the fix makes the npm-ci spec fail (1 of 38 specs, 0 passed, 1 failed), and with the fix both pass (2 of 38 specs, 2 passed).

Checklist

• Code compiles correctly
• Relevant tests were added (unit)
• Relevant logs were added — n/a, no new failure paths
• Formatting and linting run locally successfully (gofmt, go vet clean)
• All tests pass — see note below
• UA review
• Design is documented — n/a
• Extended the README / documentation, if necessary — n/a, no user-facing config change
• Open source is approved

Note on the full suite: internal/commands (the package changed here) is green — 73 of 73 specs. cmd and internal/artifacts fail on my machine, but they fail identically on unmodified master (I re-ran them on a clean checkout to confirm), so those are environment-related and not caused by this change. No new dependencies, so go mod vendor output is unchanged.

[cla-assistant]

All committers have signed the CLA.