Automated fix version sync for CVEs from GitHub release labels to Jira

### Summary

Enable keycloak-github-bot to automatically update Jira issue fix versions based on release labels applied to CVE issues in keycloak-private, eliminating manual cross-referencing and giving the Continuous Delivery team visibility into upcoming fixes.

### Problem statement

There's a disconnect between where CVE work happens (GitHub/keycloak-private) and where release planning for RHBK happens (Jira):

1. Secalert creates Jira issue trackers for CVEs
2. Engineers fix CVEs in keycloak-private and apply release labels (e.g., `26.0.x`, `24.0.x`) versions that will include the fix
3. Someone from the security team has to manually find each CVE in keycloak-private, check its release labels, then update the corresponding Jira issue with the correct fix version(s)
4. Until that manual step happens, the Continuous Delivery team has no visibility into which fixes are coming in their release backlog

This manual matching is error-prone and is creating delays. The CD team ends up flying blind, and the security team wastes time on it instead of real security work.

### Proposed solution

Automate the label-to-fix-version sync:

1. Jira issue trackers are created by secalert — no change here
2. Bot monitors keycloak-private for release labels — when a CVE issue gets a release label (e.g., `26.0.5`), the bot detects it
3. Bot updates the corresponding Jira issue — sets the fix version field to match the release label(s)
4. Continuous updates — if labels are added or removed on GitHub, the bot syncs those changes to Jira

The bot already knows about CVE IDs from the existing flow, so it has the linkage needed to match GitHub issues to Jira issues.

### Current

```mermaid
flowchart LR
subgraph Current["Current workflow"]
direction TB
A1[Secalert creates Jira issue] --> B1[Human checks keycloak-private for CVE]
B1 --> C1[Human reads release labels]
C1 --> D1[Human updates Jira fix version]
D1 --> E1[CD team finally sees the fix in backlog]
end
```

### Proposal

```mermaid
flowchart LR
subgraph Proposed["Proposed workflow"]
direction TB
A2[Secalert creates Jira issue] --> B2[Bot detects release labels on keycloak-private]
B2 --> C2[Bot updates Jira fix version]
C2 --> D2[CD team sees fix in backlog immediately]
end
```

### Value & benefits

|Benefit|Who benefits from it|Impact|
|---|---|---|
|Real-time release visibility|Continuous Delivery team|Fixes appear in their backlog as soon as labels are applied, not days later|
|Eliminated manual toil|Security team|No more cross-referencing GitHub and Jira to update fix versions|
|Reduced errors|Everyone|No more missed or incorrect fix versions from human error|
|Faster release cycles|CD team, product|No delays waiting for someone tell which CVEs must go into the RHBK releases|

### User stories / scenarios

**Scenario: Fix labeled for multiple releases**

> An engineer fixes CVE-2025-98765 in keycloak-private and applies labels `26.0.5` and `24.0.12` (backport). Within minutes, the bot updates the Jira issue tracker to show fix versions `26.0.5` and `24.0.12`. The CD team planning the 26.0.5 release immediately sees this CVE in their backlog without anyone pinging them or manually updating Jira.

**Scenario: Label removed after backport decision changes**

> A backport to `24.0.x` is initially planned, but later the team decides not to backport. The engineer removes the `24.0.12` label from the GitHub issue. The bot detects the removal and updates Jira, removing `24.0.12` from the fix versions. The CD team's backlog reflects reality without manual intervention.

### Acceptance criteria

- When a release label is added to a CVE issue in keycloak-private, the bot updates the corresponding Jira issue's fix version within minutes
- When a release label is removed, the bot removes that fix version from Jira
- Multiple release labels result in multiple fix versions on distinct Jira issues
- The bot handles label additions/removals on existing issues, not just newly labeled ones
- The bot logs all fix version updates for auditability
- If no corresponding Jira issue exists yet, the bot checks again on the next time

### Out of scope

- Creating Jira issues (secalert handles that)
- Syncing fix versions from Jira back to GitHub labels
- Modifying the release labeling in keycloak-private
- Any other Jira fields beyond fix version

### Discussion

_No response_

### Motivation

_No response_

### Details

_No response_

Start by tracing the existing CVE linkage and Jira issue-tracker flow in keycloak-github-bot, then identify how GitHub label additions and removals can be observed. Done means release labels on keycloak-private keep the corresponding Jira fix versions synchronized, with audit logs and retry behavior when the Jira issue is not yet available.

Written by the indexing model from the issue text.