ci(renovate): fix the invalid go constraint and skip indirect digest updates

[vmaerten]

Summary

Follow-up to #2951. The constraintsFiltering: "strict" rule added there never took effect — #2943 still bumps the go directive after a rebase, and Renovate now reports a repository problem:

⚠️ Invalid constraint used with strict constraintsFiltering

Two cumulative causes.

The configured constraint is invalid. Before filtering, Renovate validates each configured constraint against the datasource versioning — semver for Go modules (datasource/common.ts#L248). Our "go": "1.25" has no patch component, so isValid() rejects it, Renovate logs the warning and continues, skipping filtering altogether. Aligning the value on the go.mod directive fixes it.

Worth noting: that constraint was never the one doing the filtering. The gomod manager already extracts the directive itself under the reserved %goMod key (manager/gomod/extract.ts#L89), and the go datasource compares candidate releases against that same key (releases-goproxy.ts#L350). So constraintsFiltering works with no constraint configured at all — constraints.go only ever governed which Go binary Renovate runs, which is why it is corrected here rather than removed.

Filtering only ever sees releases. github.com/planetscale/vtprotobuf reaches us as a digest update — an indirect dep pinned to a pseudo-version, tracked against upstream HEAD:

| github.com/planetscale/vtprotobuf | indirect | digest | 0393e58 → 8ae5a48 |

There is no release metadata to inspect, so no constraint-based mechanism can ever intercept it. Hence the second rule: stop chasing upstream HEAD for indirect deps. They still move whenever the direct dep pulling them in moves.

Test plan

• renovate.json parses
• After merge: rebase/retry chore(deps): update all non-major dependencies #2943, confirm the repository problem is gone, that vtprotobuf is absent from the table, and that go.mod stays at go 1.25.10

Notes

Digest updates on direct deps are untouched, so mvdan.cc/sh keeps tracking upstream as intended. charmbracelet/ultraviolet, indirect and digest-tracked, will now hold until bubbletea moves it.

Neither rule is a hard guarantee: a transitive bump via MVS could still raise the directive, since gomodTidy runs regardless of what Renovate proposes. Dropping gomodTidy from postUpdateOptions would be the only airtight fix, at the cost of no longer tidying automatically. Worth revisiting if this recurs.