Populate the Go module graph without the toolchain

[knutwannheden]

Motivation

GoResolutionResult fell back to go.sum whenever parse-time go list / go mod graph failed. go.sum is a hash inventory of the module graph rather than a build list — it deliberately records versions MVS rejected — so anything reading resolvedDependencies reported modules that are not in the build, with no way to detect that it was in that state. This left Go the weakest of the ecosystems on graph availability: rewrite-maven resolves the graph itself via MavenPomDownloader with no mvn process, rewrite-javascript reads it from a lockfile committed to the repo, and only Go depended on an external process succeeding at parse time.

• The prerequisite for a Go DependencyInsight (moderneinc/customer-requests#3017) is that transitive dependency questions have a trustworthy answer, or a truthful "I don't know".

Summary

• resolvedDependencies now means the resolved build list, derived in priority order from the toolchain, vendor/modules.txt, or the main module's require block. The last leans on Go 1.17+ module graph pruning, which records an indirect require for every module providing a transitively imported package and so makes the expanded require block a build list — derivable with no toolchain, no module cache and no network. go.sum joins in by (path, version) to supply hashes; rows matching no build-list member are versions MVS rejected and stay unselected.
• Graph edges are enriched onto whatever build list was derived by reading each member's own go.mod from the module cache at cache/download/<escaped>/@v/<version>.mod, whose requires are that module's edges — the same set go mod graph prints. Because the build list has already selected every version, this needs no version resolution.
• Two fields make the state legible instead of inferred: resolutionSource (TOOLCHAIN / VENDOR / GO_MOD / GO_SUM_ONLY) and per-dependency selected, with hasBuildList() and hasGraph() helpers. Recipes use the helpers rather than comparing constants, so further sources can be added without touching call sites. hasGraph() reads the data rather than resolutionSource, because edges are an enrichment any source can carry — a vendored module with a warm cache has both.
• GoModParser.withSumHashes merges go.sum into the build list rather than replacing it wholesale, which was safe only while the Go side always returned it empty. Its sibling lookup resolves through relativeTo, since a repo-relative source path is an identifier rather than a filesystem location.

Only a pre-pruning module now falls back to a bare hash inventory, and it reports GO_SUM_ONLY rather than presenting the inventory as a build list.

Test plan

• 21 new Go parser tests: pruning gate and pre-1.17 fallback, replace binding (versioned, wildcard, non-matching), go.sum hash join, unselected rejected versions, vendor grammar including ## explicit / => / per-module go version, module-cache path and version escaping, cache misses leaving deps nil rather than empty, and cache enrichment over a vendored build list
• Codec round-trip mutation-checked — deleting the two send lines fails it with a wire desync rather than passing on zero values
• Full Go suite green (go test ./...)
• 175 rewrite-go Java tests across unit and integTest, 0 failures, 0 errors — including MarkerRoundTripTest over the real Java → Go → Java RPC path with assertions on both new fields. One pre-existing environmental skip (Assumptions.assumeTrue(recipesPath != null))