Add standard "known vulnerabilities" metadata field, sourced from OSV

Start with PythonRepositoryVersionViewSet and the existing VulnerabilityReport.vulns data, then compare the response-shape precedent in #1282 for PackageYank. The work is done when Simple API and JSON API responses expose the standard vulnerabilities field from OSV results, with the issue's open question about automatic scanning resolved.

Is your feature request related to a problem? Please describe.

pulp_python already has vulnerability-scanning capability: a scan action on PythonRepositoryVersionViewSet (added in #1013/#1012) queries OSV.dev and stores results in pulpcore's VulnerabilityReport model. However, that data is not exposed through the standard PyPI "known vulnerabilities" metadata field described in the PyPI JSON API spec — the existing scan output lives in its own report resource, not in the Simple API / JSON API response shape that standard PyPI tooling expects, and today's scan is manual/on-demand only. Tooling that relies on the standard field for vulnerability visibility (e.g. Red Hat Trusted Libraries / the pulp-trustify effort) has no way to consume it from pulp_python today.

Describe the solution you'd like

Surface the existing VulnerabilityReport.vulns data (see above) through the Simple API / JSON API responses as the standard vulnerabilities field, following a comparable per-(name, version) marker pattern to native PackageYank support (#1282) for the API-shape/serializer side. OSV remains the data source underneath — no new scanning backend needed. Open design question to resolve here: scanning today is manual/on-demand only — deciding whether it should also trigger automatically (e.g. on sync/upload) is in scope for this issue.

This is agreed phase-1 scope for the Pulp-Trustify integration effort — complex/custom scanning and Trustify-specific data-source integration are intentionally deferred to a later phase (see context below).

Describe alternatives you've considered

• Implementing this in pulp-service instead — ruled out; pulp-service (the hosted Pulp team) is an external stakeholder for this effort, not a place for this logic to live.
• Full Trustify-backed scanning/library integration now — deferred; this issue is scoped narrowly to the standard OSV-sourced vulnerabilities field, decoupled from the broader pulp-trustify core-library work happening in parallel in pulp/pulp_trustify.
• Building a new scanning mechanism from scratch — ruled out; #1013/#1012 already added an OSV.dev-backed scan pipeline (VulnerabilityReport model, scan action) that this issue should extend rather than duplicate.

Additional context

• Part of the broader Trustify integration program (Red Hat Trusted Libraries / Calunga); tracked upstream at pulp/pulp_trustify.
• Related PRs: #1013/#1012 (existing OSV.dev-backed scan pipeline — VulnerabilityReport model, scan action — the mechanism this issue extends), #1282 (native PackageYank content model — API-shape precedent for surfacing a per-package marker).
• Filed on behalf of Otávio Fernandes; Gerrod Ubben to be notified separately once this is actually filed — he may pick it up next sprint, or review a contribution from Otávio.