fix(vuln): save package-specific severity before severity selection

[DmitriyLewen]

Description

Refactored vulnerability severity processing logic to fix package-specific severity handling. The changes move the package-specific severity processing earlier in the flow and ensure vendor severities are properly stored before the main severity selection logic runs.

Found mistakes

RedHat vulnerabilities don't have DataSource and use incorrect SeveritySource (redhat instead of redhat-oval.
This PR fixes these mistakes, updates tests and improves severity selection logic for redhat.

Reason

The original code had a logical issue where package-specific severity handling was interfering with the main severity selection process. When a vulnerability had a SeveritySource set (indicating package-specific severity), the code was overriding the selected severity and source, but this happened after the main severity selection logic had already run.

Benefits

• Correct vendor severity storage: Package-specific severities are now properly stored in VendorSeverity map before main processing
• Improved severity selection: Main severity selection logic (getSeverity) now runs with complete vendor severity data available
• Better separation of concerns: Package-specific severity handling is now clearly separated from main severity selection
• Preserved existing behavior: All existing functionality is maintained while fixing the logical flow issue

Examples:

Before:

➜  trivy -q image debian -f json --vuln-severity-source nvd | grep SeveritySource | sort -u
          "SeveritySource": "debian",
          "SeveritySource": "nvd",

After:

➜  ./trivy -q image debian -f json --vuln-severity-source nvd | grep SeveritySource | sort -u
          "SeveritySource": "nvd",

Related issues

• Close bug(vulnerability): --vuln-severity-source doesn't work for package-specific severity (e.g. Debian) #9191

Related PRs

• feat: add --vuln-severity-source flag #8269

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[DmitriyLewen]

Reopened from #9192 after recreating the fork.

[github-actions]

This PR is stale because it has been labeled with inactivity.