feat: Implement vulnerability token signing and verification utilities

- Added VulnTokenSigner for signing JWT tokens with specified algorithms and keys.
- Introduced VulnTokenUtilities for resolving tenant and subject claims, and sanitizing context dictionaries.
- Created VulnTokenVerificationUtilities for parsing tokens, verifying signatures, and deserializing payloads.
- Developed VulnWorkflowAntiForgeryTokenIssuer for issuing anti-forgery tokens with configurable options.
- Implemented VulnWorkflowAntiForgeryTokenVerifier for verifying anti-forgery tokens and validating payloads.
- Added AuthorityVulnerabilityExplorerOptions to manage configuration for vulnerability explorer features.
- Included tests for FilesystemPackRunDispatcher to ensure proper job handling under egress policy restrictions.

docs/benchmarks/scanner/deep-dives/windows.md

@@ -0,0 +1,47 @@
+# Windows Package Ecosystem — Coverage Deep Dive
+
+## Competitor snapshot
+- **Trivy**: No analyzers for Windows Installer (MSI), WinSxS manifests, or Chocolatey feeds. Official coverage tables enumerate Linux distributions only.
+- **Grype**: Syft catalogers focus on Linux ecosystems; no Windows package collectors or matchers are available.
+- **Snyk CLI**: Container/open-source scans rely on SaaS services; Windows host-level package scanning is not advertised. Snyk AppRisk references depend on SaaS integrations rather than offline collectors.
+
+## Proposed StellaOps roadmap
+In-depth design detail lives in `../../modules/scanner/design/windows-analyzer.md`.
+1. **MSI/WinSxS collector**
+   - Traverse `Windows/WinSxS/Manifests` and `Windows/Installer` to harvest component manifests, linking to installed products via the installer database.
+   - Parse MSI tables (Product, Component, File) to emit authoritative component records with product codes, upgrade codes, and install context.
+2. **Chocolatey/NuGet-based packages**
+   - Inspect `ProgramData/Chocolatey/lib` and `ProgramData/Chocolatey/packages.config` for package metadata, including embedded nuspec files and checksums.
+   - Resolve package sources and cache feed metadata to support offline replay.
+3. **Registry-backed inventory**
+   - Query `HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall` and equivalent Wow6432Node path to capture legacy installers (EXE/PDB) with version/signature hints.
+   - Record install source, publisher, and install location for cross-reference with filesystem collectors.
+4. **Capability signals**
+   - Detect installed services (`System32/config/SYSTEM` registry hive), scheduled tasks, and driver packages to feed Policy Engine capability predicates.
+   - Capture Authenticode signatures and catalog (.cat) references to support trust enforcement.
+5. **Offline parity**
+   - Package MSI schema definitions, Chocolatey feed snapshots, and Windows update catalog indexes into Offline Kit bundles.
+   - Provide hashing guidance for large binaries to avoid excessive Offline Kit growth (use external CAS references where possible).
+
+## Detection technique comparison
+| Technique | Artifacts | Merge strategy | Notes |
+| --- | --- | --- | --- |
+| MSI database parsing | `Windows/Installer/*.msi` database tables (Product, Component, File) | Emit component records keyed by ProductCode/ComponentCode; merge with WinSxS manifests using file hashes. | Requires custom MSI reader (Jet/COM-free) compatible with offline bundles. |
+| WinSxS manifest enumeration | `Windows/WinSxS/Manifests/*.manifest` | Map assemblies to catalog signatures and MSP patches; merge with MSI output for provenance. | Provides side-by-side assembly version info and language resources. |
+| Chocolatey package inspection | `ProgramData/Chocolatey/lib/*/tools` & nuspec metadata | Produce package records with source feed URL, checksum, install scripts. | Feed metadata snapshot required to resolve dependencies offline. |
+| Registry uninstall keys | `HKLM/HKCU ... /Uninstall/*` | Fill gaps for legacy installers (non-MSI); merge by install path and display name with file system evidence. | Use hive exports during scan to avoid registry API dependencies. |
+| Service/driver mapping | `System32/config/SYSTEM` hive, `System32/DriverStore/FileRepository` | Generate capability overlays (services, drivers) for Policy Engine gating. | Helps differentiate drivers requiring elevated scrutiny (e.g., kernel-mode). |
+| Competitor baseline | — | No competitor tool offers deterministic Windows package coverage with offline support. | Opportunity to differentiate once demand justifies scope. |
+
+## Backlog / coordination
+- Follow demand capture in `docs/benchmarks/scanner/windows-macos-demand.md`. Once Windows signals meet thresholds, open engineering backlog (see proposed IDs below).
+- Coordinate with Offline Kit guild on distributing MSI schema, Chocolatey feed snapshots, and driver catalog signatures.
+- Engage Policy guild on required predicates (Authenticode trust, driver risk classes, service start modes).
+
+## Open design questions
+| Topic | Question | Owner |
+| --- | --- | --- |
+| MSI parsing library | Build custom reader or embed open-source MSI parser? Must be AGPL-compatible and offline-ready. | Scanner Guild |
+| Driver risk classification | Should Policy Engine treat kernel-mode drivers differently by default? | Policy Guild |
+| Authenticodes & catalogs | Where do we verify signature/certificate revocation (scanner vs policy)? | Security Guild |
+| Registry access | Will scanner access registry hives directly or require pre-extracted exports? | Scanner + Ops Guild |