Aggregate FindJavaVersion to one row per repository

[timtebeek]

Summary

• Convert FindJavaVersion to a ScanningRecipe keyed on GitProvenance.origin, so each git repository contributes exactly one row regardless of how many modules or compilation units it contains
• When modules in a repository disagree on JDK, retain the row with the lowest target compatibility (tiebreak: lowest source) — the migration floor for the repository
• No schema change: JavaVersionTable.Row keeps its two original columns, sourceVersion and targetVersion

Problem

The recipe originally kept a transient HashSet<JavaVersion> seen on the recipe instance. Two things conspired to drop rows:

1. JavaVersion excludes its UUID from equals/hashCode.
2. The Moderne CLI reuses one recipe instance across every repository in a working-set run (verified empirically — see below).

The combination silently dropped every repository's row except the first one processed. The previous attempt on this branch removed the dedup and emitted one row per compilation unit — correct counts, but thousands of identical rows per project and no aggregation at the repository level (the unit that actually matters for portfolio-wide JDK inventory).

Solution

• ScanningRecipe<Map<String, Row>>. The scanner reads JavaVersion and GitProvenance markers from each JavaSourceFile and merges into the accumulator.
• Key: origin:<GitProvenance.origin> → project:<JavaProject.getId()> → version:<JavaVersion.getId()> (in that fallback order). Prefixed string keys keep the three namespaces from colliding and make the accumulator readable at a glance.
• Merge: lower targetVersion wins; tiebreak on lower sourceVersion.
• generate flushes accumulated rows to the data table. No recipe-instance mutable state.

Validation

Unit tests

• multiModuleRepositoryCollapsesToOneRow — modules sharing one GitProvenance produce a single row
• heterogeneousVersionsInOneRepoPickLowestTarget — Java 8 + Java 17 modules in one repo produce a single row showing Java 8
• identicalJavaVersionMarkersAcrossRepositoriesAreEachReported — three repos sharing one JavaVersion produce three rows (regression for moderneinc/customer-requests#2409)
• withoutGitProvenanceFallsBackToPerProject — no GitProvenance → one row per JavaProject
• ./gradlew test --tests '*FindJavaVersionTest*' passes

CLI reproduction on real repositories

Ran mod run working-set --recipe org.openrewrite.java.migrate.search.FindJavaVersion against the 8 repositories in the Spinnaker organization (clouddriver, echo, fiat, front50, halyard, kayenta, kork, spinnaker-gradle-project — 4448 source files in clouddriver alone, varied submodule structures).

To confirm the bug is real on the CLI (not just a theoretical concern) I swapped in the pre-fix code from commit 4beeb8a1 and reran identically:

Code version	Rows in aggregated CSV	Per-repo distribution
Pre-fix (transient seen HashSet)	1	Only clouddriver (processed first) wrote a JavaVersionTable.csv.gz. All 7 other repos: no data table file emitted at all.
This PR (ScanningRecipe)	8	One row per repo. 7 × Java 17, 1 × Java 11 (spinnaker-gradle-project).

This proves three things on real LSTs:

1. The CLI does reuse the recipe instance across repositories in a working-set run. The buggy seen HashSet leaked across all 8 repos and silently dropped 7 of them.
2. Multi-module aggregation works: clouddriver (4448 source files, ~30 submodules) collapses to a single row under the fix. Previously this would have been the only row, masking the much worse cross-repo bug.
3. Cross-repo non-collapse works (regression for #2409): 7 repositories sharing Java 17 each appear as their own row instead of merging into one.

The "lowest version wins" branch (heterogeneous JDKs within one repo) isn't exercised by Spinnaker — every repo's submodules agree on a single JDK — but it's covered deterministically by the unit test.

Fixes moderneinc/customer-requests#2409