Generate with a toolchain whose flate output matches the fixtures - #2559

Fixes #2556.

Two commits: the Makefile change is 20 lines, the regeneration is 57 files of base64. Reviewing them separately is much easier than reviewing the squash.

The problem

Generated code embeds the OpenAPI spec deflate-compressed, so its base64 depends on the toolchain's compress/flate — whose output changed in Go 1.27. Regenerating on a newer toolchain rewrites the blob in ~57 committed files, and a real change is easy to miss among that noise.

The blobs currently on main were produced by Go 1.27, which is newer than the go directive allows and newer than either version CI tests, so nobody on a supported toolchain could reproduce them.

The fix

Every toolchain from the go directive through 1.26.x produces identical bytes:

So generate keeps using whatever Go is installed, and only steps down a toolchain at or past the change — to the version go.mod declares, derived from the go directive so there is nothing to keep in sync by hand.

Pinning unconditionally was the obvious move and is the wrong one: it would send everyone on a supported version to download an exact patch release they do not need, and a Makefile export overrides a GOTOOLCHAIN=local set by corporate policy, turning a policy setting into a build failure.

The second commit regenerates the fixtures to the range's bytes, so contributors on a supported Go reproduce them with their own toolchain — no pin, no download.

Verification

On a real Go 1.27.1 install:

• make generate leaves all 58 files byte-identical.
• The same run under GOTOOLCHAIN=local produces 0c76b0f6ff16 — matching what is committed on main today, which independently confirms those blobs came from 1.27.
• Regenerating again restores the correct bytes, so the fallback is self-healing.

make test and make lint pass on 1.27.1 against fixtures generated at 1.25/1.26 — the decode path does not care which encoder wrote them. Every changed line in the second commit is a swaggerSpec base64 line; the decoded spec content is unchanged.

Also confirmed while investigating step 3 of the issue: nothing automated regenerates. No workflow runs make generate, and neither renovate.json nor the shared oapi-codegen/renovate-config has a postUpgradeTasks that does. The churn in 89284708 came from a maintainer regenerating by hand on a renovate branch. So no CI change is needed for this to hold.

Notes

• There is a TODO on the fallback: it can be deleted once the go directive reaches 1.27, at which point every supported toolchain agrees again.
• This should land promptly — any open PR whose author regenerated on 1.27 will conflict across 57 files.
• It does not help downstream users, who get the same churn in their own generated code when they upgrade Go. Making the embedded spec encoding toolchain-independent would, but storing it uncompressed measures 5.0x larger (70 KiB → 353 KiB across these fixtures), so that deserves its own discussion rather than being folded in here.

_{🤖 Investigated and drafted with Claude Code.}