go/build/v2: honor vendor input

[rakshitgondwal]

Summary

• make go/build/v2 honor its existing vendor input
• preserve existing module or workspace vendor trees, including patched vendored sources
• generate a vendor tree only when one is missing, then force go build to consume it with -mod=vendor
• add an end-to-end regression test covering preserved, generated, disabled, and workspace vendoring

Why

go/build/v2 has declared vendor since it was introduced in #2538, but the input is never consumed. This surfaced while reviewing chainguard-dev/stereo#268366.

Unconditionally regenerating vendor/ is unsafe because callers can patch vendored source before building. Only forcing -mod=vendor is also insufficient for existing callers that set vendor: true without a pre-existing tree. This change handles both cases and leaves the default vendor: false behavior unchanged.

Validation

• go test ./pkg/build/...
• compiled the new e2e recipe for x86_64
• validated YAML formatting/parsing and git diff --check
• exercised the fixture directly with Go 1.24, verifying:
  • an existing patched module vendor tree is preserved and consumed
  • vendor: false does not force vendor mode
  • a missing module vendor tree is generated
  • a missing workspace vendor tree is generated with go work vendor

The new go-build-v2-vendor-build-test.yaml job provides the same coverage in Melange's e2e suite.

Melange Pull Request Template

Functional Changes

• This change can build all of Wolfi without errors (describe results in notes)

Notes: Full Wolfi was not rebuilt locally. The change is opt-in and the focused module/workspace regression coverage is included in this PR.

SCA Changes

• Examining several representative APKs show no regression / the desired effect (details in notes)

Notes: Not applicable; this does not change SCA behavior.

Linter

• The new check is clean across Wolfi
• The new check is opt-in or a warning

Notes: Not applicable; this does not add or change a linter.

[xnox]

I hoped to not support vendor trees at all. But I see why this might be needed.

A quick check, do we have an overlap in functionality between this and omnibump?

For example - if omnibump bumps dependencies, does it already regenerates vendor tree? and separately, if patches are applied - surely we shouldn't touch vendor tree at all then?

I just hope not to support vendor trees here at all if possible. And only add this, if we truly have a usecase. Will ping you on slack to discuss what can be done here. If there is more than one package/version-stream that needs it, then happy to add this in.