feat(manager/gomod): extract the go and toolchain directives as constraints

[jamietanna]

Changes

As part of future changes in #42567 to surface the constraints of a
given Go module, we should first extract the constraints from the
package file.

To make this simpler for users, we can make sure we extract these at
parse time:

• the toolchain directive becomes the go constraint, as it is the
  toolchain actually running Go, and mirrors how a constraints.go
  would be expected to control the go toolchain version for
  Containerbase
• the go directive becomes a new go-mod constraint, which keeps it
  separate from the version of the Go toolchain actually used to run

Context

Please select one of the below:

• This closes an existing Issue: Closes #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

AI assistance disclosure

Did you use AI tools to create any part of this pull request?

Please select one option and, if yes, briefly describe how AI was used (e.g., code, tests, docs) and which tool(s) you used.

• No — I did not use AI for this contribution.
• Yes — minimal assistance (e.g., IDE autocomplete, small code completions, grammar fixes).
• Yes — substantive assistance (AI generated non‑trivial portions of code, tests, or documentation).
• Yes — other (please describe):

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

The public repository:

[jamietanna]

Or maybe go-directive?

[viceice]

Suggested change

	'go-mod': '1.23',
	'go': '1.23',

it should match what we use for constraints / install-tool

[jamietanna]

So this is a case where we want to keep them separate - the go directive in go.mod is the source compatibility of the code, which is different to the toolchain / go constraint that will actually run the code

[viceice]

Suggested change

	'go-mod': '1.23',
	'goMod': '1.23',

or

Suggested change

	'go-mod': '1.23',
	'%go-mod': '1.23',

what about a prefix to better distinghish from real tool constraints? so we don't have an issue if we add a go-mod tool later. tool names will ever only be lowercase. @ will be used for npm scopes, so we can't use that.

[jamietanna]

Making it an explicit alternative sounds good - note that #42589 has highlighted we do already have gomodMod for

renovate/lib/modules/manager/gomod/artifacts.ts

Lines 71 to 96 in 50a2bac

	if (updateImportCommands.length > 0) {
	let installMarwanModArgs =
	'install github.com/marwan-at-work/mod/cmd/mod@latest';
	const gomodModCompatibility = constraints?.gomodMod;
	if (gomodModCompatibility) {
	if (
	gomodModCompatibility.startsWith('v') &&
	isValid(gomodModCompatibility.replace(regEx(/^v/), ''))
	) {
	installMarwanModArgs = installMarwanModArgs.replace(
	regEx(/@latest$/),
	`@${gomodModCompatibility}`,
	);
	} else {
	logger.debug(
	{ gomodModCompatibility },
	'marwan-at-work/mod compatibility range is not valid - skipping',
	);
	}
	} else {
	logger.debug(
	'No marwan-at-work/mod compatibility range found - installing marwan-at-work/mod latest',
	);
	}
	updateImportCommands.unshift(`go ${installMarwanModArgs}`);
	}

(But we don't want to use that here)

[viceice]

Suggested change

	'go-mod': '1.23',
	'go': '1.23',

it should match what we use for constraints / install-tool

[jamietanna]

It'd be nice if we could extract this as a ^1.23 (or in a way that allows 1.23 to be treated as 1.23.x) to allow patch bumps

[jamietanna]

We'll want to rethink this to tweak with how we do it in https://github.com/renovatebot/renovate/blob/HEAD/lib/modules/manager/gomod/artifacts.ts#L195 - we should have these consistent, so we're aware we'll always have a constraints?.go set to the toolchain to use