Project-level vulnerability deduplication

### Current Behavior

Currently, if a project has several subprojects or components that are aggregated together, multiple instances of the same vulnerability are reported individually on the metrics in the UI. As a result, projects with several versions affected by a single vulnerability can appear to be affected by several vulnerabilities when viewed in the UI, only showing the granular breakdown once the user drills down far enough.

In practice and for our usecase (a linux distribution), it means that an actual vulnerability count in the high thousands becomes hundreds of thousands to millions of detections in the UI, causing a great deal of noise and difficulty in prioritizing triage work.

### Proposed Behavior

It would be nice if there was a way to enable project-level deduplication of vulnerabilities such that the same vulnerability affecting multiple subprojects or components doesn't result in an inflated number of vulnerabilities in the UI metrics.

The issue can be mitigated by using latest-version or tag aggregation, but it doesn't solve the entire problem for us. For example, vulnerabilities tend to be associated with the source package, but that is not always the case - a package built in Go generally depends on a virtual `golang-any` package that never has vulnerabilities associated with it, but the final architecture-specific package resolves and depends on the actual `golang-1.24` package which *does* have vulnerabilities.

If we were to use tags to only include the vulnerabilities of the source package, we would miss real vulnerabilities from the resolved package. However, if we were to include both the source package and the architecture-specific packages, we would see duplicated vulnerabilities in the metrics scaling by the number of architectures.

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/main/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this enhancement was already requested

No files, tests, or entry points are named. Start by tracing how project-level vulnerability counts are aggregated for subprojects and components, then define the deduplication identity and configuration scope; done means repeated instances no longer inflate UI metrics while drill-down retains the granular breakdown.

Written by the indexing model from the issue text.