Super Issue for NVD conversion issues

There are cases where our NVD conversion is incorrectly resolving version ranges, or attributing them incorrectly.
This issue is to serve as a super-issue so we can aggregate cases together, and keep on top of all the issues and expected fixes.

I expect a large number of version resolution issues should be resolved through the CVEList conversion.

## Summary of current known issues:
* **Single-Version & Enumerated Versions Attribution:** The converter struggles with records where only one specific version (or a release candidate) is affected, often incorrectly generating a range that includes all prior versions (e.g., #3938). This is also an issue for versions that are enumerated rather than given a range.
* **Default "Introduced: 0" False Positives:** When a starting version isn't explicitly defined in NVD, the converter often defaults to `introduced: 0`. This incorrectly marks the entire early history of a project as vulnerable (e.g., #3522, #3519).
* **Unstructured Description Parsing:** Critical version range data is often buried in the text description of a CVE rather than the structured fields. The current extraction logic frequently misses these or attributes them to the wrong package (e.g., #3519, #3550).
* **Git Tag/Commit Mapping Gaps:** There is a persistent mismatch when converting NVD-reported versions into Git SHAs for the `GIT` ecosystem, leading to incomplete "Affected Versions" lists (e.g., #3161). I believe this to be to do with being on separate branches.