fix(gradle): resolve buildSrc dependency constants and verify fresco

[mstykow]

Summary

• resolve committed Kotlin buildSrc constants when Gradle manifests use symbolic refs such as Deps.AndroidX.*, Deps.Bolts.*, GradleDeps.*, and TestDeps.*, then keep the resulting dependency attached to the referencing build.gradle instead of duplicating it onto the supporting .kt files
• verify facebook/fresco @ c991a692a254358d1cf56c5b4b06e6c5dd96cfab with compare-outputs --profile common, record the final checkpoint in docs/BENCHMARKS.md, and regenerate docs/benchmarks/scan-duration-vs-files.svg
• add parser, scan, and golden coverage for the new Gradle behavior, including a focused buildsrc-constants fixture tree that exercises nested Kotlin object constants plus simple $version interpolation

Scope and exclusions

• Included:
  • static lookup of nearby committed buildSrc Kotlin constants under buildSrc/src/main/java and buildSrc/src/main/kotlin
  • bounded resolution of nested object / const val references and simple $name / ${name} interpolation when they collapse to literal group:name:version coordinates
  • Fresco benchmark verification and benchmark-doc refresh
  • focused parser, scan, and golden regression coverage
• Explicit exclusions:
  • no Gradle execution, no Kotlin compilation, and no buildSrc code evaluation
  • no attempt to resolve helper methods, arbitrary expressions, remote catalogs, or other non-constant Gradle indirection
  • unresolved symbolic refs without a nearby static match still stay omitted rather than guessed

Intentional differences from Python

• Provenant now upgrades static buildSrc constant references to exact Maven coordinates when the supporting Kotlin files are committed nearby. In the Fresco case, imagepipeline-base/build.gradle can therefore surface concrete dependencies like androidx.exifinterface:exifinterface:1.3.7 and com.parse.bolts:bolts-tasks:1.4.0 instead of leaving the reference unresolved.
• When no matching buildSrc constant exists, Provenant intentionally prefers an honest unknown over placeholder package identities. We do not emit a dependency entry for unresolved refs such as Deps.AndroidX.androidxAnnotation; we also do not fall back to ScanCode-style placeholders like pkg:maven/AndroidX.
• The dependency remains attributed to the manifest that declared it. In the verified Fresco run, the resolved dependency entries have datafile_path: "imagepipeline-base/build.gradle" plus extra_data.symbolic_ref, while the supporting buildSrc/*.kt files remain ordinary scanned source files with package_data: [].

Follow-up work

• Created or intentionally deferred:
  • deferred: broader support for non-constant Gradle indirection (helper functions, arbitrary expressions, external runtime state)
  • deferred: unrelated common-profile text-detection noise in Fresco docs/static assets, since the benchmark triage here was focused on resolving the real Gradle package/dependency gap before recording the checkpoint
  • recorded compare artifacts:
    • initial triage run: .provenant/compare-runs/20260429T191522Z-fresco-70123/
    • final verified run: .provenant/compare-runs/20260429T193659Z-fresco-98279/
  • local validation used while iterating:
    • cargo test buildsrc_kotlin_constants
    • cargo test parsers::gradle::tests::
    • cargo test gradle_scan_test::tests::
    • cargo test --features golden-tests test_golden_groovy_buildsrc_constants

Expected-output fixture changes

• Files changed:
  • testdata/gradle-golden/groovy/buildsrc-constants/build.gradle-expected.json
  • plus the matching buildsrc-constants fixture inputs and the golden registration in src/parsers/gradle_golden_test.rs
• Why the new expected output is correct:
  • the expected dependency coordinates come from committed buildSrc Kotlin constants that live at the repo root in the fixture tree, so the parser can resolve them statically without executing Gradle
  • the expected output intentionally shows the dependency on the referencing build.gradle with symbolic_ref metadata, while the supporting .kt files themselves continue to produce no package data
  • this matches the verified Fresco behavior and keeps the scanner honest when no static buildSrc match exists