Leverage NVD CPE Dictionary deprecation chains to bridge CPE vendor renames in vulnerability matching

### Current Behavior

#### Background

NVD periodically renames CPE vendors. The CPE Dictionary API exposes this authoritatively via `deprecated` / `deprecatedBy` fields. As of June 5, 2026, all 181 `cpe:2.3:a:arm:mbed_tls:*` entries are marked deprecated, each pointing to a `cpe:2.3:a:trustedfirmware:mbed_tls:*` replacement (verifiable: `GET https://services.nvd.nist.gov/rest/json/cpes/2.0?cpeMatchString=cpe:2.3:a:*:mbed_tls`). This pattern is not unique to mbed_tls (haxx:curl → curl_project:curl is another known example).

NVD backfills old CVE configurations slowly or not at all. The result is a permanent split: 16 CVEs for mbed_tls still reference arm:mbed_tls in their criteria, while 2 newer CVEs reference trustedfirmware:mbed_tls. Because DT stores CPE match criteria verbatim from CVE configurations, neither `cpe:2.3:a:arm:mbed_tls:2.28.8:*:*:*:*:*:*:*` nor `cpe:2.3:a:trustedfirmware:mbed_tls:2.28.8:*:*:*:*:*:*:*` in a component's SBOM finds all 18 CVEs. The component is silently under-analyzed regardless of which CPE the SBOM author chooses.

#### Existing workarounds are insufficient

- Wildcard vendor (`cpe:2.3:a:*:mbed_tls:2.28.8:*`) catches all CVEs but requires users to know the trick, increases false positive risk, and is not produced by standard SBOM tooling
- Multiple CPEs per component are not supported by CycloneDX 1.x
- Suppression/audit does not address missed detections

#### Related issues
- Distinct from #3146, which requested user-defined CPE aliases. This proposal uses NVD's own CPE Dictionary — the same authoritative source DT already trusts for all other CPE data. No user input or SBOM changes are required.
- Distinct from #2390 (which asks DT to warn users when their component's CPE is deprecated so they can update the SBOM): this proposal makes deprecation chains transparent to vulnerability matching automatically — no SBOM update can fix the underlying problem, because old CVEs still reference the deprecated vendor string regardless of what the user puts in their SBOM.

### Proposed Behavior

DT syncs the NVD CPE Dictionary (`/rest/json/cpes/2.0`) alongside the existing CVE sync and uses the `deprecated` / `deprecatedBy` relationships to expand CPE vendor lookups during vulnerability analysis. When a component CPE is analyzed, DT also queries against any CPE vendors that NVD has declared as deprecated predecessors of or canonical replacements for the component's vendor+product pair.

A component with either `cpe:2.3:a:arm:mbed_tls:2.28.8:*:*:*:*:*:*:*` or `cpe:2.3:a:trustedfirmware:mbed_tls:2.28.8:*:*:*:*:*:*:*` finds all 18 CVEs without any SBOM modification.

### 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

Start by tracing the existing CVE sync and vulnerability-analysis entry points, then inspect how DT stores and compares CPE match criteria. Use the NVD CPE Dictionary endpoint and its deprecated/deprecatedBy relationships as the reference; done means either vendor form finds the old and new CVE criteria without SBOM changes.

Written by the indexing model from the issue text.