Support upstream/downstream vulnerability relationships in search results and affected project counts

### Current Behavior

Dependency-Track currently exposes vulnerability aliases, but upstream/downstream relationships, such as the relationship between CVEs and RHSAs, are not visible in the vulnerability search results.

Unlike aliases, RHSA advisories are not in a one-to-one relationship with CVEs:

- one CVE can be associated with multiple RHSAs
- one RHSA can be associated with multiple CVEs

This relationship is represented as upstream/downstream in OSV.

In our workflow, the primary entry point for vulnerability impact analysis is usually the CVE.

For example, `CVE-2026-22007` is associated with 62 RHSA advisories.

However, when searching for `CVE-2026-22007` in Dependency-Track, there is no visible relationship with the related RHSA advisories.

As a result, to determine the real impact, users currently need to:

1. Search for `CVE-2026-22007` in Dependency-Track
2. Notice that related RHSAs are not shown
3. Go to Red Hat or OSV to identify all RHSA advisories related to the CVE
4. Search each RHSA manually in Dependency-Track
5. Check the affected project count for each RHSA

For CVEs such as `CVE-2026-22007`, which has 62 related RHSA advisories, this process is very time-consuming and error-prone.

This can lead users to miss affected projects when starting the analysis from the CVE.

### Proposed Behavior

Dependency-Track should handle upstream/downstream vulnerability relationships in a similar way to aliases, especially for vulnerability impact analysis.

When a user searches for a CVE, related downstream advisories such as RHSAs should be visible and/or included in the affected project count.

For example, `CVE-2026-22007` has 62 related RHSA advisories. Searching for this CVE should either:

1. Show the related RHSA advisories in the search results, including their `Projects` count
2. Or aggregate the affected project counts from the related RHSAs into the CVE result

Example expected result for option 1:

| Name | Relationship | Related vulnerability | Projects |
|---|---|---|---:|
| `CVE-2026-22007` | Upstream | - | `0` |
| `RHSA-2026:9683` | Downstream | `CVE-2026-22007` | `N` |
| `RHSA-2026:9693` | Downstream | `CVE-2026-22007` | `N` |
| `...` | Downstream | `CVE-2026-22007` | `N` |

Example expected result for option 2:

| Name | Related vulnerabilities | Projects |
|---|---|---:|
| `CVE-2026-22007` | 62 related RHSA advisories | `N` |

This would allow users to immediately identify whether they are impacted when starting their analysis from the CVE, without manually searching each related RHSA.

### 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 or tests are named. Start by tracing the vulnerability search-results and affected-project-count entry points, then review how OSV upstream/downstream relationships are represented; done means a CVE search exposes related RHSA advisories with project counts or clearly aggregates those counts, with coverage for the stated relationship behavior.

Written by the indexing model from the issue text.