Stop osv-scanner resolving manifests against a registry

[kingchenc]

The job I added in #115 fails on every version bump, and #117 is the first one
to prove it. Its default enricher resolves pom.xml against Maven Central, and
two of ours -- examples/java and bindings/java/benchmarks -- depend on
org.wickra:wickra-backtest at whatever version the tree carries. A bump sets
that to a version the release has not published yet, so the lookup fails:

failed resolving org.wickra:wickra-backtest-examples[Concrete:0.1.1]:
version org.wickra:wickra-backtest[Concrete:0.1.1]: not found
Total 0 packages affected by 0 known vulnerabilities
exit code 127

The scan found nothing wrong. The job died looking for an artefact the bump
exists to create, and it would have done so on every release from here on. A
check that goes red for a reason other than what it checks is worse than no
check: it teaches whoever sees it that this job's failures do not mean anything.

--no-resolve turns that enricher off. The cost is real and belongs in the
comment rather than in a commit nobody rereads: Maven and NuGet manifests are
now scanned for their direct dependencies only. Everything pinned in a lockfile
is unaffected -- Cargo.lock, package-lock.json and go.mod need no resolution and
are still scanned transitively -- and cargo-deny in the same job covers the Rust
graph, which is most of the dependency surface here.

Verified both directions rather than assumed. Against the bumped tree the
failure reproduces exactly (exit 127) and the flag clears it (exit 0, no
issues). Against a fixture pinning time 0.1.44 and lodash 4.17.20 the flag
changes nothing about detection: exit 1, four advisories across two ecosystems,
including the npm one that only a lockfile scan can see.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!