[davidmoralesz]

What changed, and why

Adds ci-go.yml, a reusable workflow for Go modules, so a Go repo gets the same centralized coverage ci-java-gradle.yml gives a Gradle one. The first consumer will be studiobimo/zero-trust.

One job, in this order:

1. go mod verify and go mod tidy -diff
2. Format check (golangci-lint fmt --diff)
3. Lint (golangci-lint run)
4. go test -race with a coverage profile, summarised in the job summary
5. govulncheck
6. go build

Design choices:

• Versions are pinned in the consumer, next to the code. go.mod names the Go version; .golangci-lint-version names the linter version, with an input as the fallback. This mirrors how ci-java-gradle reads .java-version.
• The linter and govulncheck run with go run pkg@version, not a downloaded binary. A golangci-lint built with an older Go than the code refuses to run, and building it with the module's own toolchain rules that out. It is also the same command a developer runs locally.
• No secrets are read, so it is safe on pull requests from forks.

Also adds the workflow-templates/ci-go starter and the README row. No existing workflow changes, so nothing breaks for current consumers.

How it was tested

• Passed locally: actionlint, zizmor, prettier, gitleaks and check-action-pins (the lefthook pre-commit run), plus check-github-workflows from a consumer's pre-commit config.
• Every command the job runs was run by hand against the zero-trust module on macOS with Go 1.27.2, golangci-lint v2.14.0 and govulncheck v1.8.0, and passed.
• Not tested: the workflow has never run in GitHub Actions. This repo has no Go code, so there is no self-* caller, and zero-trust is not on GitHub yet, so there is no cross-repo run to link. Unproven until then: actions/setup-go reading go-version-file and its cache paths, the go run builds on an Ubuntu runner, and the coverage summary step.

Suggested before merging or moving v1: point zero-trust's wrapper at this branch's SHA in a draft PR and link the run here.

Checklist

• Title is a Conventional Commit;
  branch follows Conventional Branch
• At most 20 files changed (split with gh stack if not)
• Third-party uses: pinned to a full SHA with a # vX.Y.Z comment
• Our own actions referenced with $/ from a workflow, SHA-pinned from a template
  (sh .devtools/check-action-pins.sh) — none are used here; the script passes
• permissions: {} at workflow level; each job asks for the least it needs
• Breaking change for consumers is called out above, since they ride the floating v1 — none