[K9VULN-14776] Emit pyproject manifest metadata

[rjcoulter22]

Motivation

Manifest-only pyproject.toml scans need enough metadata for downstream SCA enrichment: ranged dependencies should keep their declared range, and manifest-only dependencies should be marked for transitive enrichment.

Documentation

Document	Link or Detail
RFC	Resolving version ranges for SCA
Incident	N/A
Jira Ticket	K9VULN-14776

Summary

Adds manifest-only dependency metadata for pyproject.toml scans.

• Preserves exact pins as Version.
• Preserves PEP 508 and Poetry ranges as VersionRange, including wildcard ranges like 1.*.
• Emits datadog:version-range only for ranged dependencies.
• Emits datadog:requires-transitive-enrichment=true for all emitted pyproject manifest dependencies.
• Allows ranged manifest dependencies to emit with an empty CycloneDX version and unversioned PyPI PURL.

Testing

• New tests were added for new logic.
• Existing tests were updated for new logic.

Recovery

Notes for on-call - select only one:

• The change can be rolled back.
• Do not roll back. Why?:

[datadog-prod-us1-4]

🎯 Code Coverage (details)
• Patch Coverage: 82.03%
• Overall Coverage: 84.96% (-0.04%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 19880cc | Docs | Datadog PR Page | Give us feedback!}

[rjcoulter22]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 19880cccce

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve distinct pyproject version ranges

When the same dependency name is declared with different pyproject constraints, this creates separate PackageDetails entries that all have an empty Version and only differ by VersionRange. Later sanitizeScannedPackages gives each of them the same unversioned PURL (for example pkg:pypi/requests), and purl.Group keys components by that PURL, so PackageMetadata.Merge keeps only the first version-range value and silently drops the other constraint. This produces an SBOM/API payload with an incorrect range whenever a package is constrained differently across prod/optional/dev groups or files; the range needs to be part of the grouping identity or the ranges need to be explicitly combined before grouping.

Useful? React with 👍 / 👎.