fix(release): the checksum key is singular, so GoReleaser rejected the whole config

[amiddavid]

One word: checksums: → checksum:. It blocks every release, and it is mine, from #141.

What was broken

GoReleaser v2 has no checksums field — the key has always been singular. An unknown field is not ignored; GoReleaser refuses to start:

starting release
release failed after 0s
  error=
  │ yaml: unmarshal errors:
  │   line 71: field checksums not found in type config.Project

So the release path produced nothing: no archives, no checksums.txt, no assets. Not a wrong filename — a pipeline that never began. Any v* tag pushed to main today publishes a release with zero artifacts, and the tag is public by the time anyone finds out.

Introduced in b08e5435 (#141), and worth stating rather than glossing: #141 added the workflow_dispatch snapshot entry to release.yaml, whose stated purpose in that same commit was that "the release path gets exercised before there is a tag to regret". It had never been run. Its first run failed on this line — which is the outcome it was added to produce, at the cost of the release being broken for every day in between. The lesson is not about the field name: a workflow that has never executed is not a safeguard, it is an intention.

A second defect on the same line, quietly

The name_template: checksums.txt under that key was correct all along, and inert. GoReleaser's default checksum filename is {{ .ProjectName }}_{{ .Version }}_checksums.txt, while the plugin's install.sh fetches checksums.txt — and that is the only integrity check in the download path, deliberately fail-closed (checksum_unavailable → refuse, never install-anyway).

So even in a world where the config had loaded, every install would have refused with a missing checksums file. Fixing the key fixes both.

Verified by running it, not by reading it

Same workflow, same snapshot mode, on this branch — run 33877011327, success, against the identical run on main that failed (33876270319):

context-guru_0.1.1-next_darwin_amd64.tar.gz
context-guru_0.1.1-next_darwin_arm64.tar.gz
context-guru_0.1.1-next_linux_amd64.tar.gz
context-guru_0.1.1-next_linux_arm64.tar.gz
checksums.txt

All four platforms, and the archive names match exactly what install.sh constructs (context-guru_${VERSION#v}_${OS}_${ARCH}.tar.gz). The pure-Go assertion step passed as part of the same run.

What this still does not prove

Snapshot mode deliberately does not publish, so the publish half — creating the GitHub release, uploading assets, the contents: write token path — remains unexercised until a real tag. That is irreducible without cutting one; the first v* tag is still the first time that code runs.

Context

v0.1.0 already exists as a tag (2026-07-27, e7c59907, by @OsherElhadad) with a release attached and zero assets — it predates release.yaml, so nothing ever built for it. The next real release therefore wants to be v0.1.1, which is also what GoReleaser's own incpatch chose for the snapshot above.

Committed through the contents API rather than a local checkout so that #160's worktree stayed untouched; the branch is one commit off main and touches one file.