bug(python): pylock.toml dependencies without a version are dropped from the dependency graph #11411

Description

When a dependency in [[packages.dependencies]] of pylock.toml (PEP 751) is specified by name only, e.g. { name = "beta" }, Trivy silently drops it from the dependency graph.
As a result, the SBOM (CycloneDX dependsOn, SPDX relationships) is incomplete, and the package shows up directly under pylock.toml instead of under its parent.
Vulnerability detection is not affected.

Reproduced on v0.75.0 and main:

mkdir pylock-name-only && cd pylock-name-only
cat > pylock.toml <<'EOF'
lock-version = "1.0"
created-by = "minimal-reproducer"

[[packages]]
name = "alpha"
version = "1.0.0"
dependencies = [{ name = "beta" }]

[[packages]]
name = "beta"
version = "2.0.0"
EOF
trivy fs --format cyclonedx --output bom.json .
jq -c '.dependencies[]' bom.json

alpha@1.0.0 is expected to depend on beta@2.0.0, but its dependsOn is empty.
If the selector is changed to { name = "beta", version = "2.0.0" }, the relationship appears.

Such lock files are produced by real tools, e.g. Pex (see test_issue_2877.py).

Discussed in #11402

Root cause

PEP 751 allows [[packages.dependencies]] to contain only the minimum set of keys that identifies the [[packages]] entry unambiguously (packages.dependencies).
If there is only one package with that name in the lock file, version can be omitted.

Parse() in pkg/dependency/parser/python/pylock/parse.go builds the dependency ID from name and version.
For { name = "beta" } the ID is beta, while the package is stored under beta@2.0.0.
The dependency is then discarded by the "Filter out dependencies that are not in the package list" filter, without any log message.

Implementation challenges

1. Ambiguous selectors

A single pylock.toml can contain several entries with the same name, e.g. different versions for different environments (marker).
In that case a name-only selector is ambiguous, and picking one of the entries arbitrarily is not an option.
PEP 751 also allows an entry to be narrowed down by other keys (e.g. vcs), which Trivy doesn't read at the moment.

2. Cache

Analyzer results are cached.
Without bumping version in pkg/fanal/analyzer/language/python/pylock/pylock.go, users keep cached results without these dependencies, and the fix will look like it doesn't work.

3. Tests

All dependencies in pkg/dependency/parser/python/pylock/testdata/pylock.toml currently have a version, so this case isn't covered by tests.
It should be checked whether the golden file of the integration test integration/testdata/pylock.json.golden changes.

Before implementation

Before implementing, the approach should be discussed and agreed on in this issue, and only then should the implementation start.