ci: bump Go, golangci-lint, codespell, and runners

[kolyshkin]

• Test matrix: 1.24.x (go.mod minimum) and 1.26.x (latest); drop 1.25.x.
• GO_VERSION for the validate jobs: 1.25 -> 1.26.
• golangci-lint: v2.4 -> v2.12.
• codespell: 2.4.1 -> 2.4.3.
• Runners: ubuntu-24.04 -> ubuntu-26.04.

The actions themselves are already kept current by dependabot.

[kolyshkin]

CI bumps; easy to review; PTAL @opencontainers/cgroups-maintainers

[AkihiroSuda]

Can we just test oldstable and stable

[AkihiroSuda]

Suggested change

	go-version: [1.24.x, 1.26.x]
	# the minimum version corresponds to go.mod
	go-version: [1.24.x, 1.26.x]

[kolyshkin]

added

        # Make sure to have version from go.mod included here.

[kolyshkin]

Can we just test oldstable and stable

@AkihiroSuda we also have to specify the version from go.mod, and in case this version is accidentally the same as "oldstable" or "stable", we have the test running twice on the same Go version.

If we use numbers, we can clearly see if there's redundancy here.

What do you think?

[kolyshkin]

Can we just test oldstable and stable

@AkihiroSuda we also have to specify the version from go.mod, and in case this version is accidentally the same as "oldstable" or "stable", we have the test running twice on the same Go version.

If we use numbers, we can clearly see if there's redundancy here.

What do you think?

More arguments towards keeping the versions explicit (as opposed to using stable/oldstable and derive Go version from go.mod) are in #15.

[thaJeztah]

Yeah, pros and cons to each; for some repositories, I'm using go.mod itself as "minimum", and "oldstable", "stable" for the upper-bound, but that's usually for repositories that don't get frequent updates. If we want to use fixed versions, we could consider adding tip to get an early warning for things that may break in the near future.

Here's what I did on some of those repositories;

• ci: use go.mod for "minimum" Go version, and use custom name moby/go-archive#29

Even if we decide not to use oldstable, stable, using the custom names could still be useful to get stable names in the CI tasks (although we handled it here with the "all-done" I think?)