Grype should match Ubuntu packages against ESM (Expanded Security Maintenance / Ubuntu Pro) fix data, not just the standard Ubuntu security data. Today a CVE that Canonical only fixes in Pro/ESM either shows up as wont-fix on base or falls off entirely, and there's no way for a Pro user to see the ESM fix that actually resolves it.

We already do the equivalent thing for RHEL EUS, so this is mostly following that pattern: model ESM as a distro "channel" and let the matcher consider ESM fixes when the channel is on.

Assumptions:

• Plain ESM only. esm-infra + esm-apps (the Ubuntu:Pro:X.YY:LTS tier). This is the case that matters for the vast majority of Pro users.
• FIPS, FIPS-updates, Realtime, and Nvidia-BlueField are out of scope for now. Those are rebuilt/forked binaries on their own version lines. We must never fold them into the base or esm channel, and never infer base vulnerability from them. They are deferrable to their own detection-gated channels later; this issue does not cover them.
• ESM applies per LTS release, not per minor version, so there's no RHEL-style .elN_M reachability logic to port.
• The ESM channel gates on detection/opt-in, not a version window (esm-apps covers universe for the full support window, including years a release is still in standard support).

Rough approach:

• vunnel: emit the ESM fix data under a channel-suffixed namespace (ubuntu:24.04+esm), mirroring how the RHEL provider emits rhel:9.4+eus.
• grype: register an esm fix-channel for ubuntu and add a channel-aware dpkg matcher (two-pass disclosure/resolution merge) modeled on the RHEL EUS matcher. The os transformer already splits +esm into OperatingSystem.Channel... so no change there needed.
• syft (optional): detect Ubuntu Pro/ESM so the channel can auto-enable (in containers the reliable signal is installed +esm package versions).