Proposal: add `redhat-support` skill for CVE lookup and validation

[gkneighb]

cluster-update/update-advisor references a redhat-support skill in its "Investigate with other skills" section and in its failure-modes list:

Never fabricate Jira issue keys, KB article IDs, or CVE numbers. Use the redhat-support skill to get real data.

The skill doesn't exist yet, so any CVE ID update-advisor reports today is unverified. Proposing to add it.

Scope (MVP)

Wraps the public Red Hat Security Data API (https://access.redhat.com/hydra/rest/securitydata, no auth required). Two endpoints, used in combination:

• GET /cve/<CVE-ID>.json — full vulnerability record (severity, CVSS, affected products, fix state, advisories, references)
• GET /cve.json — search with filters (package, advisory, severity, after/before, cwe, per_page)

Concrete capabilities:

• Validate that a CVE ID exists in Red Hat's record
• Get severity, CVSS3, and Bugzilla summary for a CVE
• Determine which Red Hat products are affected and in what state (fix_state vs shipped advisory)
• Find the RHSA that fixes a CVE for a given product family (exact match or family-match including EUS/AUS/E4S)
• List CVEs by package, by advisory, or filtered by severity + date

Out of scope

The public security data API does not expose CVRF/CSAF documents, direct advisory bodies, or KB solutions (/solutions/<id> requires auth). The skill calls this out in references/security-data-api.md and directs callers to surface the public access.redhat.com/errata/ URL when full advisory contents are needed. If those become important, they can land as a follow-up — KB lookup in particular would need a different access pattern.

Format and testing

Matches cluster-update/product-lifecycle's convention: SKILL.md with curl + jq examples and a references/security-data-api.md with the field-by-field schema.

• Every curl + jq example in SKILL.md was executed against the live API and verified to produce the documented output.
• The skill was end-to-end tested by spawning an independent agent with no prior context, giving it two realistic CVE questions ("is CVE-2024-3094 a concern on RHEL 9, and what's the severity?" and "which RHSA fixed CVE-2024-1086 on RHEL 9 proper, excluding EUS?"), and confirming it correctly read the skill, ran the documented commands, and produced accurate structured answers.
• That test surfaced three real issues (a startswith ambiguity between RHEL 9 and RHEL 9 EUS variants, undocumented duplicate entries in affected_release[], and a gap in the schema reference for cvss3 sub-fields). All three are addressed in the implementation.

Open questions

1. Location. Staged under support/redhat-support/ to align with @harche's planned support/jira/ ([WIP] skills: Add support skills (jira) #9), since both are support-system integrations. Happy to move if a different parent fits better.
2. Errata fetching. Scoped out because no public JSON endpoint returns advisory contents — if there is one I missed, I'd add it.

A PR with the implementation will be linked shortly.