Let the release skill drive this repo, and let make drive the pipeline

The release skill only knew repos that deploy an image through a wrapper
chart. terdut-tui publishes binaries to a Gitea release and nothing else,
so its first two releases were cut by hand. It now has a .release.conf
saying KIND=binary, which the skill treats as gate, tag, wait for the
pipeline, then check what was published.

The gate had to exist as make targets for that: fmt, lint and test, the
same three the other repos have. ci.yaml and release.yaml now call them
instead of carrying their own copy of gofmt, vet and the tests, so a green
gate locally and a green pipeline are the same code and cannot drift. The
gofmt handling moved over as written, including the comment on why both of
its failure modes need catching; both fail the target, checked with a
misformatted file and an unparseable one.

The binaries job calls make dist too. DIST_TARGETS is now the one place
that says what a release contains, and dist-assets prints the names dist
builds so the skill can verify the published release against a list
instead of a count. The names are unchanged, and they are the self-updater's
contract with every installed binary: internal/updater matches
terdut-tui-<tag>-<goos>-<goarch> exactly.

CLAUDE.md gains a Release section, including that the annotated tag's
message is what appears on the release page.

Not run in the pipeline yet: make is in the golang image, as terdut-server's
CI relies on, but this repo's workflows only exercise it on the push that
carries this commit, and make dist only on the next tag. A failure in the
release workflow's test job stops the publish rather than shipping
something unchecked.

.gitea/workflows/ci.yaml

@@ -56,34 +56,8 @@ jobs:
             git clone --depth=1 --branch "$REF_NAME" "$REPO_URL" .
           fi
 
-      # This exists because `go vet` does not look at import order: the move to
-      # git.ryuvia.com rewrote every import path without re-sorting, the new path sorts
-      # before github.com/..., and both repos sat unformatted through a green CI run and
-      # a release before anyone noticed.
-      #
-      # Both of gofmt's failure modes need handling, and they are not alike. A file that
-      # is merely misformatted is listed on stdout with exit 0 -- so the failure has to
-      # be raised by hand. A file that does not parse is the opposite: nothing on stdout
-      # and exit 2, which a naive `[ -n "$unformatted" ]` reads as success. The first
-      # draft of this step had exactly that hole.
-      - name: Format
-        run: |
-          if ! unformatted=$(gofmt -l .); then
-            echo "::error::gofmt could not parse the tree"
-            gofmt -l .    # re-run unredirected so the parse errors reach the log
-            exit 1
-          fi
-          if [ -n "$unformatted" ]; then
-            echo "::error::not gofmt'd:"
-            echo "$unformatted"
-            gofmt -d .
-            exit 1
-          fi
-
-      - name: Vet
-        run: go vet ./...
-
-      # Covers the API client against a stub server, the Update state machine, and View
-      # rendering -- all three are pure enough to test without a terminal.
-      - name: Test
-        run: go test ./...
+      # The Makefile is the single definition of the gate -- gofmt with both of its failure
+      # modes handled, go vet, and the tests -- so this is exactly what a developer and the
+      # release skill run. See the comments on the targets for why each is shaped as it is.
+      - name: Format, vet and test
+        run: make fmt lint test