feat: Enhance SBOM composition with policy findings and update CycloneDX package

- Added `PolicyFindings` property to `SbomCompositionRequest` to include policy findings in SBOM.
- Implemented `NormalizePolicyFindings` method to process and validate policy findings.
- Updated `SbomCompositionRequest.Create` method to accept policy findings as an argument.
- Upgraded CycloneDX.Core package from version 5.1.0 to 10.0.1.
- Marked several tasks as DONE in TASKS.md, reflecting completion of SBOM-related features.
- Introduced telemetry metrics for Go analyzer to track heuristic fallbacks.
- Added performance benchmarks for .NET and Go analyzers.
- Created new test fixtures for .NET applications, including dependencies and runtime configurations.
- Added licenses and nuspec files for logging and toolkit packages used in tests.
- Implemented `SbomPolicyFinding` record to encapsulate policy finding details and normalization logic.

bench/Scanner.Analyzers/lang/README.md

@@ -3,10 +3,23 @@
 This directory will capture benchmark results for language analyzers (Node, Python, Go, .NET, Rust).
 
 Pending tasks:
-- LA1: Node analyzer microbench CSV + flamegraph.
-- LA2: Python hash throughput CSV.
-- LA3: Go build info extraction benchmarks.
-- LA4: .NET RID dedupe performance matrix.
-- LA5: Rust heuristic coverage comparisons.
-
-Results should be committed as deterministic CSV/JSON outputs with accompanying methodology notes.
+- LA1: Node analyzer microbench CSV + flamegraph.
+- LA2: Python hash throughput CSV.
+- LA3: Go build info extraction benchmarks.
+- LA4: .NET RID dedupe performance matrix.
+- LA5: Rust heuristic coverage comparisons.
+
+Results should be committed as deterministic CSV/JSON outputs with accompanying methodology notes.
+
+## Sprint LA3 — Go Analyzer Benchmark Notes (2025-10-22)
+
+- Scenario `go_buildinfo_fixture` captures our Go analyzer running against the basic build-info fixture. The Oct 23 baseline (`baseline.csv`) shows a mean duration of **35.03 ms** (p95 136.55 ms, max 170.16 ms) over 5 iterations on the current rig; earlier Oct 21 measurement recorded **4.02 ms** mean when the analyzer was profiled on the warm perf runner.
+- Comparative run against Syft v1.29.1 on the same fixture (captured 2025-10-21) reported a mean of **5.18 ms** (p95 18.64 ms, max 23.51 ms); raw measurements live in `go/syft-comparison-20251021.csv`.
+- Bench command (from repo root):\
+  `dotnet run --project bench/Scanner.Analyzers/StellaOps.Bench.ScannerAnalyzers/StellaOps.Bench.ScannerAnalyzers.csproj -- --config bench/Scanner.Analyzers/config.json --out bench/Scanner.Analyzers/baseline.csv`
+
+## Sprint LA4 — .NET Analyzer Benchmark Notes (2025-10-23)
+
+- Scenario `dotnet_multirid_fixture` exercises the .NET analyzer against the multi-RID test fixture that merges two applications and four runtime identifiers. Latest baseline run (Release build, 5 iterations) records a mean duration of **29.19 ms** (p95 106.62 ms, max 132.30 ms) with a stable component count of 2.
+- Syft v1.29.1 scanning the same fixture (`syft scan dir:…`) averaged **1 546 ms** (p95 ≈2 100 ms, max ≈2 100 ms) while also reporting duplicate packages; raw numbers captured in `dotnet/syft-comparison-20251023.csv`.
+- The new scenario is declared in `bench/Scanner.Analyzers/config.json`; rerun the bench command above after rebuilding analyzers to refresh baselines and comparison data.

bench/Scanner.Analyzers/lang/dotnet/syft-comparison-20251023.csv

@@ -0,0 +1,2 @@
+scenario,iterations,sample_count,mean_ms,p95_ms,max_ms
+syft_dotnet_multirid_fixture,5,2,1546.1609,2099.6870,2099.6870

bench/Scanner.Analyzers/lang/go/syft-comparison-20251021.csv

@@ -0,0 +1,2 @@
+scenario,iterations,sample_count,mean_ms,p95_ms,max_ms
+syft_go_buildinfo_fixture,5,2,5.1840,18.6375,23.5120