perf: speed up dependency registration in Bom.validate()

[inspired-geek]

Description

Bom.validate() ensured every component/service had a Dependency entry by calling register_dependency() once per component. register_dependency() locates an existing entry with a linear next(filter(...)) scan over the dependency collection, so the registration loop is O(n²). Because the JSON/XML outputters always call validate() during serialization, serializing large BOMs (thousands of components) stalls for minutes.

This resolves "already registered" via a set of refs, keeping the loop linear. Observable output is unchanged; test_regression_issue_1006 covers correctness.

Benchmark — serializing a BOM of N library components (output_as_string, JSON v1.6):

N	before	after
1000	0.14s	0.05s
2000	0.48s	0.13s
4000	1.75s	0.26s
8000	6.70s	0.63s

Scaling goes from ~quadratic (≈4× per 2×N) to linear (≈2× per 2×N).

Resolves or fixes issue: #1006

AI Tool Disclosure

• My contribution includes AI-generated content, as disclosed below:
  • AI Tools: Claude Code
  • LLMs and versions: Claude Opus 4.8
  • Prompts: Investigate slow SBOM serialization on large BOMs, identify the O(n²) hotspot, and propose a minimal fix with a regression test. The diagnosis (validate() → register_dependency linear scan) and the set-based fix were produced with assistance; I reviewed the change and ran the benchmarks, regression test, and linters (isort/flake8/mypy) to verify it.

Affirmation

• My code follows the CONTRIBUTING.md guidelines

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 duplication

Metric	Results
Duplication	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[jkowalleck]

i dont see how the test proves the expected behavior - a speed improvement. what am i missing?
could you please elaborate?

[inspired-geek]

@jkowalleck good question — you're right: test_regression_issue_1006 only guards correctness (that the change doesn't alter which dependencies end up registered). The speedup itself is shown by the benchmark in the PR description, and I deliberately avoided a wall-clock assertion since timing tests are flaky in CI.

To actually guard the complexity, I've pushed test_regression_issue_1006_scales_linearly: it counts BomRef equality comparisons performed during validate() for n and 2n components and asserts the count grows ~linearly rather than ~quadratically — no timing involved, so it's CI-stable.

• previous O(n²) scan: ~22k → ~84k comparisons (ratio ~3.9) → test fails
• indexed implementation: ~1.6k → ~3.7k comparisons (ratio ~2.2) → test passes

So it fails on the regression and passes on the fix. Happy to reformulate (e.g. a different counter or threshold) if you'd prefer.