test: stabilize Maven-resolving tests + e2e CSV against Maven Central rate limits

[KunalSin9h]

Problem

Several CI checks fail non-deterministically due to Maven Central rate-limiting (HTTP 429), not code regressions:

• run-test → pkg/parser (Test_MavenPomXmlParser_*) and pkg/readers (TestDirectoryReaderEnumPackages) resolve Maven dependencies live from Maven Central. CI runners share egress IPs that Maven Central frequently throttles, and osv-scalibr's resolver does not retry on 429, so resolution fails. The pkg/parser RemoteParent fixture (spring-boot-starter-parent) made it worse by burst-fetching ~200 BOM POMs, but even light fixtures (a single junit dependency) get 429'd once the IP is hot.
• run-e2e scenario-11 (scenario-11-code-csvreport.sh) diffs vet's live output against a hardcoded golden CSV. Upstream published a new langchain advisory (GHSA-gr75-jv2w-4656), so vet emitted a row the golden file lacked.

Fix (test/CI only — no production code, no fixture changes)

1. pkg/parser — skip the Maven parser tests when resolution fails with a Maven fetch/registry error (429 / unreachable). Any other error still fails the test, preserving regression coverage.
2. pkg/readers — gate the pom.xml-bearing enumeration cases on an error-based probe: resolve a fixture pom through the same parser the directory reader uses, and skip those cases when Maven Central is rate-limited. (A full resolution is used as the probe rather than a single HTTP ping, so the signal reflects what the cases actually do.)
3. e2e CSV golden — add the new langchain advisory row to the expected report.

Why skip rather than retry / lighter fixture

• A lighter fixture alone is insufficient: CI runner IPs arrive pre-throttled, so even a ~4-request resolution gets 429'd.
• Retrying re-fires the same burst and re-trips the limit.
• osv-scalibr fetches via http.DefaultClient internally, so there is no clean per-request retry injection without globally swapping the transport.

Skip-on-unavailable is the idiomatic pattern for tests that depend on an external service. The tests still validate fully when Maven Central is reachable.

Note

A deeper, separate issue remains: vet's Maven pom.xml resolution has no 429 resilience, which can also affect real users scanning large (e.g. Spring Boot) poms. That is a production change worth tracking independently.

🤖 Generated with Claude Code

[safedep]

SafeDep Report Summary

No dependency changes detected. Nothing to scan.

View complete scan results →

_{This report is generated by SafeDep Github App}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 12.41%. Comparing base (ed5b09d) to head (c9a6321).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #747      +/-   ##
==========================================
- Coverage   12.41%   12.41%   -0.01%     
==========================================
  Files         372      372              
  Lines       49231    49231              
==========================================
- Hits         6114     6111       -3     
- Misses      42632    42634       +2     
- Partials      485      486       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.