Add unit tests for SBOM ingestion and transformation

- Implement `SbomIngestServiceCollectionExtensionsTests` to verify the SBOM ingestion pipeline exports snapshots correctly.
- Create `SbomIngestTransformerTests` to ensure the transformation produces expected nodes and edges, including deduplication of license nodes and normalization of timestamps.
- Add `SbomSnapshotExporterTests` to test the export functionality for manifest, adjacency, nodes, and edges.
- Introduce `VexOverlayTransformerTests` to validate the transformation of VEX nodes and edges.
- Set up project file for the test project with necessary dependencies and configurations.
- Include JSON fixture files for testing purposes.

docs/modules/notify/bootstrap-pack.md

@@ -0,0 +1,59 @@
+# Notifier Bootstrap Pack Guide
+
+The Bootstrap Pack gives operators a deterministic set of configuration files
+to stage the Notifier service in sealed or fully air-gapped environments. The
+assets ship alongside the Offline Kit under `bootstrap/notify/` and can be
+copied directly onto the hosts that run `StellaOps.Notifier.WebService`.
+
+## Contents
+
+| File | Purpose |
+| ---- | ------- |
+| `notify.yaml` | Sealed-mode configuration derived from `etc/notify.airgap.yaml`. It disables external resolution by pointing to in-cluster services and honours the shared `EgressPolicy`. |
+| `notify-web.secret.example` | Deterministic template for the Authority client secret. Replace the value before running the service. |
+| `rules/airgap-ops.rule.json` | Bootstrap rule subscribing to air-gap drift, bundle import, and portable export completion events. Update channel identifiers before import. |
+| `templates/airgap-ops-email.template.json` | Email template used by the bootstrap rule with remediation guidance, checksum context, and download locations. |
+| `README.md` | This guide, also embedded in the pack for quick operator reference. |
+
+## Usage
+
+1. **Populate secrets**  – copy `notify-web.secret.example` to
+   `notify-web.secret`, change `NOTIFY_WEB_CLIENT_SECRET` to the value issued by
+   Authority, and store it with restrictive permissions (for example
+   `chmod 600`).
+2. **Drop configuration** – place `notify.yaml` in the location expected by
+   the runtime (`/app/etc/notify.yaml` for the containers we ship). The file
+   assumes MongoDB is reachable at `mongodb://stellaops:airgap-password@mongo:27017`
+   and Authority at `https://authority.airgap.local` – adjust if your
+   deployment uses different hostnames.
+3. **Import rule/template** – with the Notify CLI or REST API, import
+   `templates/airgap-ops-email.template.json` first, then
+   `rules/airgap-ops.rule.json`. Update the `channel` identifiers inside the
+   rule so they match your sealed SMTP relay (for example `email:airgap-ops`).  
+   The rule now also delivers portable export completion notices; ensure your
+   downstream process watches for checksum and location details in the payload.
+4. **Mount secrets/config** – for Docker Compose use:
+
+   ```yaml
+   volumes:
+     - ./bootstrap/notify/notify.yaml:/app/etc/notify.yaml:ro
+   env_file:
+     - ./bootstrap/notify/notify-web.secret
+   ```
+
+   In Kubernetes, create a Secret from the two files and mount them into the
+   Notifier pod.
+5. **Verify sealed mode** – with the configuration in place the Notifier
+   resolves channels that point to local relays (SMTP, syslog, file sink). Any
+   attempt to contact an external webhook is denied by `StellaOps.AirGap.Policy`
+   with remediation guidance.
+
+## How it is packaged
+
+`ops/offline-kit/build_offline_kit.py` automatically copies the configuration
+and secret template into `bootstrap/notify/` during Offline Kit creation. The
+same staging directory is what we sign and publish as the Bootstrap Pack, so
+the artefacts stay deterministic across releases.
+
+Refer to `etc/notify.airgap.yaml` if you need to regenerate the pack or build a
+site-specific overlay from source control.