feat: scope CVE fixes to container chain and improve verification

- Parse container name and package from Jira ticket summary in Step 1
- Use container_to_repo_mapping in Step 3 to scope PRs to only the
  repos that build the affected container, not all component repos.
  Fallback to all repos when container cannot be parsed.
- Add package version check (Step 5.2.1) alongside existing scanner:
  when scan doesn't find CVE, check dependency manifests directly
  (requirements.txt, go.mod, package.json) before skipping. Only skip
  when both scan AND version check find no evidence of the vulnerability.
  If package not found in manifests, still create PR with manual review note.
- Add AI Evaluations full repo chain (ragas, garak, lm-evaluation-harness,
  trustyai-service-operator, eval-hub) with container mappings

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>

Author: vmrh21

workflows/cve-fixer/.claude/commands/cve.fix.md

@@ -40,6 +40,7 @@ Summary:
      - Fetch the issue details from Jira API
      - Extract CVE ID from the issue summary
      - Extract component name from the issue
+     - Extract container name from the issue summary (see below)
      - Proceed with this single CVE
      - Skip the `/cve.find` output lookup
 
@@ -49,10 +50,34 @@ Summary:
      - Extract CVE IDs with their status from the markdown file
      - Filter for CVEs where `Status: Open` (unfixed vulnerabilities)
      - Extract component name from the find output (e.g., "AI Core Dashboard")
+     - Extract container name from each issue summary (see below)
      - Collect ALL open CVEs (no filtering)
      - Proceed with all open CVEs found
 
-   **Result**: A list of CVEs to fix with their associated Jira issues and components
+   **Extracting container and package from Jira summary (both options)**
+
+   Jira summaries follow the pattern:
+   ```
+   CVE-YYYY-XXXXX <container-name>: <package>: <description>
+   ```
+   Example:
+   ```
+   CVE-2025-66418 rhoai/odh-llm-d-routing-sidecar-rhel9: urllib3: Unbounded decompression
+   ```
+
+   Parse each summary to extract:
+   - **Container name**: the `rhoai/odh-*-rhel9` token (or similar) between the CVE ID and the first colon
+   - **Package name**: the token after the first colon (e.g., `urllib3`, `grpc-go`, `aiohttp`)
+
+   ```bash
+   SUMMARY="CVE-2025-66418 rhoai/odh-llm-d-routing-sidecar-rhel9: urllib3: Unbounded decompression"
+   CONTAINER=$(echo "$SUMMARY" | grep -oP '(?<=CVE-[0-9]+-[0-9]+ )[\w/.-]+(?=:)')
+   PACKAGE=$(echo "$SUMMARY" | grep -oP '(?<=: )[\w._-]+(?=:)')
+   ```
+
+   Store `CONTAINER` and `PACKAGE` per CVE for use in Steps 3 and 5.
+
+   **Result**: A list of CVEs to fix with their associated Jira issues, components, containers, and package names
 
 2. **Load Component-Repository Mapping**
    - Use `component-repository-mappings.json` from workspace root
@@ -92,23 +117,39 @@ Summary:
    - Proceed with mapped repository as documented below
 
 3. **Identify Target Repositories**
-   - Get list of ALL repositories from the mapping for the component
-   - **IMPORTANT**: A single component may map to MULTIPLE repositories (e.g., an upstream repo and one or more downstream repos)
-   - Each repository entry may have a `repo_type` field indicating `"upstream"` or `"downstream"`
-   - For each repository, gather:
-     - Repository name (e.g., "opendatahub-io/odh-dashboard")
-     - Default branch (e.g., "main")
-     - Active release branches (e.g., ["v2.29.0-fixes", "v2.28.0-fixes", "rhoai-3.0"])
-     - Primary target branch for CVE fixes (from `cve_fix_workflow.primary_target`)
-     - Backport targets from cve_fix_workflow
-     - Repository type (monorepo vs single package)
-     - Repo type: upstream or downstream (from `repo_type` field, defaults to upstream if absent)
-   - Create initial list of ALL candidate repositories for the fix
-   - **Multi-repo strategy**: When a component has both upstream and downstream repos:
-     - Fix upstream first, then apply the same fix to downstream repos
-     - Each repo gets its own clone, branch, PR, and verification cycle
-     - The fix in downstream repos may be a cherry-pick or re-application of the upstream fix
-     - Steps 4 through 11 are repeated for EACH repository in the list
+
+   **3.1: Use container to scope repos (preferred)**
+
+   If a `CONTAINER` was extracted in Step 1:
+   - Look up `CONTAINER` in `container_to_repo_mapping` for the component
+   - This gives the **primary repo** (e.g., `opendatahub-io/llm-d-routing-sidecar`)
+   - From the `repositories` section, collect all repos that share the same logical chain as the primary repo:
+     - The primary repo itself
+     - Any repo with the same name but different org (upstream/midstream/downstream)
+   - **This ensures only the repos relevant to that specific container get PRs** — not every repo under the component
+
+   Example: `rhoai/odh-llm-d-routing-sidecar-rhel9` maps to `red-hat-data-services/llm-d-routing-sidecar`.
+   Only process repos in the routing-sidecar chain — not inference-scheduler or batch-gateway repos.
+
+   **3.2: Fallback — use all repos**
+
+   If no `CONTAINER` was extracted (summary doesn't match expected pattern):
+   - Fall back to processing ALL repositories listed under the component
+   - Log a warning: "⚠️ Could not extract container from summary — processing all component repos"
+
+   **3.3: For each target repo, gather:**
+   - Repository name (e.g., "opendatahub-io/odh-dashboard")
+   - Default branch (e.g., "main")
+   - Active release branches (e.g., ["v2.29.0-fixes", "v2.28.0-fixes", "rhoai-3.0"])
+   - Primary target branch for CVE fixes (from `cve_fix_workflow.primary_target`)
+   - Backport targets from `cve_fix_workflow`
+   - Repository type (monorepo vs single package)
+   - Repo type: upstream or downstream (from `repo_type` field, defaults to upstream if absent)
+
+   **Multi-repo strategy**: When a container chain has upstream, midstream, and downstream repos:
+   - Fix upstream first, then apply the same fix to midstream and downstream
+   - Each repo gets its own clone, branch, PR, and verification cycle
+   - Steps 4 through 11 are repeated for EACH repository in the list
 
 4. **Clone or Use Existing Repository**
    - Always use `/tmp` for repository operations with unique dirs per repo
@@ -234,18 +275,43 @@ Summary:
    **5.2: Analyze Scan Results**
 
    - Check if the target CVE appears in the scan results
-   - **If CVE has already been fixed (not present in scan results)**:
-     - **DO NOT create a PR** — the vulnerability is already resolved
+   - **If CVE found in scan** → proceed with fix (confirmed vulnerable)
+   - **If CVE NOT found in scan** → do NOT skip immediately. Instead run Step 5.2.1 below.
+
+   **5.2.1: Package version check (when scan does not find CVE)**
+
+   Container-level CVEs may not be detected by source-level scanners because the vulnerable
+   package may be installed via RPM, a transitive dependency, or a base image layer rather
+   than declared directly in the manifest. If the scan returns no result, check the package
+   version directly:
+
+   ```bash
+   # Use PACKAGE extracted from Jira summary in Step 1 (e.g., "urllib3", "grpc-go")
+
+   # Python — check requirements files
+   grep -ri "${PACKAGE}" requirements*.txt setup.py pyproject.toml 2>/dev/null
+
+   # Go — check go.mod
+   grep -i "${PACKAGE}" go.mod 2>/dev/null
+
+   # Node — check package.json
+   grep -i "${PACKAGE}" package.json 2>/dev/null
+   ```
+
+   **Interpret results:**
+   - **Package found at a version** → compare against CVE affected version range
+     - If version is in affected range → proceed with fix
+     - If version is already patched → mark as already fixed (see below)
+   - **Package not found in any manifest** → it may be transitive or RPM-installed
+     - **Still proceed with fix attempt** — try to add/pin the package at a safe version
+     - Include note in PR: "⚠️ Package not found directly in manifests — may be a transitive or RPM-installed dependency. Manual review required to confirm fix is effective."
+   - **Both scan AND version check find nothing** → mark as already fixed:
+     - **DO NOT create a PR**
      - **Print to stdout**: "✅ CVE-YYYY-XXXXX is already fixed in [repository] ([branch]). No action needed."
-     - **Document in artifacts**: Create a brief note in `artifacts/cve-fixer/fixes/already-fixed-CVE-YYYY-XXXXX.md` with:
-       - CVE ID
-       - Repository and branch checked
-       - Scan results showing CVE is not present
-       - Timestamp of verification
-       - Note that Jira ticket may need manual closure
-     - **Move to next CVE**: Skip all remaining steps for this CVE and proceed to the next one
-     - **Note**: The Jira ticket may still be open — this is an issue management task, not a code fix task
-   - Only proceed with remaining steps for CVEs that are confirmed as current vulnerabilities in the scan
+     - **Document in artifacts**: `artifacts/cve-fixer/fixes/already-fixed-CVE-YYYY-XXXXX.md`
+     - **Note**: Jira ticket may need manual closure
+
+   - Only skip the CVE entirely when BOTH the scan AND the direct package check find no evidence of the vulnerability
 
    **5.3: Check for Existing Open PRs**