feat: recognize TuxCare ELS advisories

[Korulag]

Summary

Adds recognition of TuxCare Extended Lifecycle Support (ELS) advisories. TuxCare rebuilds distro packages with backported fixes and publishes its own advisory stream (CLSA-*), which osv.dev serves under dedicated ecosystems (TuxCare:<Distro>:<Version>). This PR routes TuxCare-rebuilt packages to those ecosystems so their advisories — and fixed versions — are reported.

Covers deb (Ubuntu / Debian) and RPM (AlmaLinux / CentOS / RHEL / Oracle Linux / CentOS Stream), including CentOS-8.4/8.5 channel detection.

Depends on #<PR 1> (RHEL-family RPM epoch handling). TuxCare's RPM ecosystems are RHEL-family and their feed encodes epochs, so correct matching requires that fix.

How it works

TuxCare-rebuilt packages carry a version marker (e.g. …+tuxcare.els3, ….tuxcare.els2). The change is built around a small supplementary-ecosystem seam rather than anything TuxCare-specific in the core:

• Query routing (internal/clients/clientimpl/osvmatcher): a marker-driven registry routes a matched package's query to the vendor ecosystem (e.g. TuxCare:AlmaLinux:9.6) instead of the base one, before the base-ecosystem gate (so CentOS/Oracle RPMs, which scalibr leaves without a base ecosystem, are still matched). This mirrors the existing single-query model; a package resolves to exactly one ecosystem.
• Vendor module (internal/tuxcare): all vendor knowledge — marker, os-release → ecosystem mapping, per-distro version granularity — lives here. Shared code touches only exported entrypoints.
• CentOS-8 channel detection (internal/scalibrextract/os/tuxcare-els-repo): CentOS-8 ELS pins a minor (8.4 vs 8.5) that os-release doesn't expose, so a small extractor reads /etc/yum.repos.d/centos8.{4,5}-els.repo and a host-context step stamps the channel onto CentOS-8 RPMs, then strips the synthetic marker before matching/reporting.
• Fixed-version reconciliation (internal/output, internal/utility/vulns): an advisory's affected entry is keyed to the overlay ecosystem while the scanned package keeps its base ecosystem, so fixed-version lookup previously found nothing and showed "No fix available". Reconciliation now normalizes the overlay prefix to the base — the same shape as the existing Ubuntu :Pro/:LTS variant handling — in both the table and the JSON/SARIF paths. (As a side effect this also fixes Ubuntu Pro fixed-version resolution in JSON/SARIF, which had the same base-vs-variant mismatch.)

Usage

RPM extraction is the experimental os/rpm opt-in; the repo-file extractor rides the artifact preset on image scans:

# container image
osv-scanner scan image <image> --experimental-plugins=os/rpm

# live / mounted host
osv-scanner scan source <root> --recursive \
  --experimental-plugins=os/rpm,os/tuxcare-els-repo \
  --experimental-no-default-plugins

Testing

• Unit + e2e coverage for routing (deb + RPM, per-distro granularity), CentOS-8 channel detection/enrichment, marker stripping, and fixed-version reconciliation.
• Verified against a live AlmaLinux 9.6 TuxCare host in three states: unpatched (full detection with correct fixed versions matching dnf), fully patched (clean), and the superseded-kernel case (an old kernel left on disk is correctly reported until removed).

Scope / notes

• Detection is by version marker; a package resolves to a single ecosystem (base or TuxCare), not both.
• Out of scope for now: Alpine (apk) and language ecosystems — the routing seam is ready for them, pending the corresponding TuxCare feeds.
• The supplementary-ecosystem mechanism is intentionally generic; happy to adjust its shape/placement based on how you'd prefer vendor advisory streams to be modeled.

Depends on: #2915

[Korulag]

@another-rex @jess-lowe could you please take a look or ping someone who can?

[Korulag]

@another-rex, could you please take a look at this one?