Build: the product SBOM does not cover core-web's npm dependencies

Description

We already generate a product SBOM: .github/actions/legacy-release/sbom-generator runs Syft
against the published dotcms/dotcms:<version> Docker image and uploads CycloneDX JSON
(legacy-release_maven-release-process.yml). This issue is not about adding SBOM generation — it
is about a blind spot in the one we have.

Syft scans the built image, and the frontend's dependencies are not in it. core-web's WAR is
packaged from ${project.basedir}/dist/** only (core-web/pom.xml, maven-war-plugin
<webResources>); node_modules never ships. What reaches the image is bundled, minified
JavaScript with no package manifests, so an image scan has nothing to identify. The ~3,000 npm
packages that went into that bundle are, as far as the SBOM is concerned, invisible.

Java dependencies are fine — they ship as jars with their own metadata, which is exactly what
Syft is good at.

First task is to confirm this, not assume it. The reasoning above is from the packaging
configuration; nobody has opened a generated SBOM and checked. Pull the artifact from a recent
release run and count npm components. If they are present, close this issue.

Why it matters

An SBOM's job is to answer "are we affected?" when a CVE lands. If the frontend tree is missing,
that answer is wrong by omission for every npm advisory — and npm is where the supply-chain
attacks of the last few years have actually happened. It is the weaker half of the inventory that
looks complete.

This is also the half the rest of #37553 has been hardening: trustPolicy: no-downgrade,
blockExoticSubdeps, and a 7-day minimumReleaseAge maturity gate all guard the npm tree at
install time. None of that is visible to someone auditing the shipped artifact.

The cheap fix pnpm 12 now offers

pnpm 12 ships pnpm sbom natively, reading the same lockfile the install uses — no new tool to
adopt or maintain. Verified locally on dotcms-postman with pnpm 12.4.2:

$ pnpm sbom --sbom-format cyclonedx
bomFormat: CycloneDX, specVersion: 1.7, components: 134
licenses identified: 132 of 134
distinct licenses: Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, MIT, Unlicense, WTFPL

Each component carries a package URL usable for CVE correlation:

{ "name": "newman", "version": "6.2.1",
  "licenses": [{ "license": { "id": "Apache-2.0" } }],
  "purl": "pkg:npm/newman@6.2.1" }

spdx is also supported via --sbom-format spdx.

Two honest limits observed: the output carries no integrity hashes (hashes: []), and 2 of
134 components had no license identified. So it is an inventory good for CVE correlation and
license audit, not a cryptographic verification of artifacts.

Proposed work

• Confirm the gap: pull the SBOM artifact from a recent release run and count npm components
• Generate a CycloneDX SBOM for core-web (and dotcms-postman) with pnpm sbom during the
  release build, while node_modules still exists
• Decide whether to merge it into the Syft document or publish it as a second artifact
  alongside it — merging is better for consumers, two files are simpler and less fragile
• Keep the format consistent with what Syft emits (CycloneDX JSON) so downstream tooling
  does not need to handle two shapes
• Pin the pnpm version used, the way the Syft invocation pins anchore_syft==1.18.1 after
  #36755

Additional Context

• Existing generator: .github/actions/legacy-release/sbom-generator/action.yml
• Parent migration: #37553 / PR #37563
• https://pnpm.io/cli/sbom

Start by pulling the SBOM artifact from a recent release run and counting npm components, then read .github/actions/legacy-release/sbom-generator/action.yml, legacy-release_maven-release-process.yml, and core-web/pom.xml. Generate a CycloneDX SBOM with pnpm sbom while node_modules exists, decide whether to merge or publish it alongside Syft output, and pin the pnpm version; done means the release artifact covers core-web dependencies.