feat(sbom): ship a CycloneDX bill of materials with every build

An air-gapped site cannot be scanned from anywhere else, so when a CVE lands the
only way to answer 'is that component here, and at what version' was to RDP in
and go looking. The frontend was the real blind spot: nothing recorded which
version of leaflet, dompurify, jspdf or html2canvas ends up inside the compiled
SPA.

scripts/generate_sbom.py emits CycloneDX 1.6 covering both ecosystems - every pin
in requirements.txt with the sha256 the installer enforces, and every package in
package-lock.json. Build-only npm packages are marked scope 'excluded' rather
than dropped, so 'not here' stays distinguishable from 'not looked for'.
Dependency edges are real: uv's '# via' comments give the Python graph and
package-lock gives the npm one.

Hand-rolled rather than cyclonedx-py plus cyclonedx-npm because both inputs are
already pinned and committed - this is a format translation, not a scan - and
because the build box may be a work PC with nothing but Python and Node. It is
deterministic by construction: same inputs, byte-identical output, so
regenerating does not churn.

Staged into the application tree by both builders, so it installs onto the
server with the app. shopdb-admin.ps1 verify reports it and searches it by
component name, which is the question actually being asked.

Packages appearing at several depths in package-lock (node_modules/vite and
node_modules/vitest/node_modules/vite) are merged, and a copy reachable outside
the dev tree makes the component count as shipped. Emitting both produced
duplicate bom-refs, which CycloneDX forbids and scanners reject; getting the dev
merge backwards would have hidden a shipped package from a CVE search.

Not covered by bundle-lock.json on purpose: its provenance is git, not the
third-party payload.

deploy/windows/installer/README.md

@@ -139,6 +139,32 @@ For the West Jefferson production server specifically, this is a **migration, no
 an upgrade** - prod runs Python 3.13 against a hand-built deployment, so it needs
 a deliberate window, a database backup, and web.config reconciled by hand.
 
+## Bill of materials
+
+Every build stages a CycloneDX 1.6 SBOM at `sbom.cdx.json`, inside the
+application tree, so it installs onto the server with the app. Both ecosystems,
+in one document:
+
+- **Python** — every pin in `requirements.txt`, with the sha256 the installer
+  enforces. Environment markers are ignored: a `sys_platform == 'win32'`
+  dependency still installs on the target.
+- **npm** — every package in `frontend/package-lock.json`. Build-only packages
+  are marked `scope: excluded` rather than dropped, so "not here" is
+  distinguishable from "not looked for".
+
+It ships to the server because an air-gapped site cannot be scanned from
+anywhere else. When a CVE lands, the answer is already on the box:
+
+```powershell
+shopdb-admin.ps1 verify                 # counts, and which bundle this is
+shopdb-admin.ps1 verify -Path leaflet   # is that component here, at what version
+```
+
+Generated by `scripts/generate_sbom.py` from files that are already pinned and
+committed, so it is a translation rather than a scan — no network, no extra
+toolchain on the build box, and byte-identical output for the same inputs. It is
+deliberately not in `bundle-lock.json`: its provenance is git, not the payload.
+
 ## Client IP addresses
 
 IIS does not set `X-Forwarded-For` on its own, and HttpPlatformHandler connects