Stop building a standalone api release artifact

The Docker image (build-docker) is the real distribution path for the
server; a raw completed-api binary alongside it was a redundant artifact
nobody was going to run directly. Renamed build-go -> build-tui since it
now only builds the tui, which is a real CLI people do run on their own
machine. Updated the release job's `needs:` and stale comments that still
said build-go.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.gitea/workflows/release.yml

@@ -17,9 +17,12 @@ env:
   REGISTRY_OWNER: sansan
 
 jobs:
-  # cmd/api and cmd/tui are pure Go (no cgo), so they cross-compile cleanly
+  # cmd/api isn't built here: the Docker image (build-docker below) is the
-  # from one Linux runner for every OS/arch below.
+  # distribution path for the server, so a standalone api binary would
-  build-go:
+  # just be a redundant artifact nobody runs directly. cmd/tui is a real
+  # CLI people run on their own machine, and it's pure Go (no cgo), so it
+  # cross-compiles cleanly from one Linux runner for every OS/arch below.
+  build-tui:
     runs-on: ubuntu-latest
     strategy:
       matrix:
@@ -41,13 +44,14 @@ jobs:
         with:
           go-version-file: go.mod
 
-      # Built with their final release filenames directly (rather than a
+      # Built with its final release filename directly (rather than a
       # generic name plus a separate archive step), so what comes out of
-      # dist/ is exactly what gets uploaded: raw executables, no zip/tar.gz.
+      # dist/ is exactly what gets uploaded: a raw executable, no
-      # One real trade-off: a raw upload doesn't preserve the Unix
+      # zip/tar.gz. One real trade-off: a raw upload doesn't preserve the
-      # executable bit the way a tar.gz would, so linux/darwin downloads
+      # Unix executable bit the way a tar.gz would, so linux/darwin
-      # need a manual `chmod +x` before running; .exe is unaffected.
+      # downloads need a manual `chmod +x` before running; .exe is
-      - name: Build api and tui
+      # unaffected.
+      - name: Build tui
         env:
           GOOS: ${{ matrix.goos }}
           GOARCH: ${{ matrix.goarch }}
@@ -56,17 +60,15 @@ jobs:
           mkdir -p dist
           ext=""
           if [ "${{ matrix.goos }}" = "windows" ]; then ext=".exe"; fi
-          suffix="${{ matrix.goos }}_${{ matrix.goarch }}${ext}"
+          go build -o "dist/${PROJECT_NAME}-tui_${{ matrix.goos }}_${{ matrix.goarch }}${ext}" ./cmd/tui
-          go build -o "dist/${PROJECT_NAME}-api_${suffix}" ./cmd/api
-          go build -o "dist/${PROJECT_NAME}-tui_${suffix}" ./cmd/tui
 
       - uses: actions/upload-artifact@v3
         with:
-          name: ${{ env.PROJECT_NAME }}-go_${{ matrix.goos }}_${{ matrix.goarch }}
+          name: ${{ env.PROJECT_NAME }}-tui_${{ matrix.goos }}_${{ matrix.goarch }}
           path: dist/*
           retention-days: 7
 
-  # cmd/gui (Fyne) uses cgo, so unlike build-go above it can't just cross-
+  # cmd/gui (Fyne) uses cgo, so unlike build-tui above it can't just cross-
   # compile with CGO_ENABLED=0. Linux is native to this runner; Windows
   # cross-compiles cleanly with the mingw-w64 toolchain (verified locally:
   # a real PE32+ GUI-subsystem .exe, linking Fyne's OpenGL/glfw backend,
@@ -97,7 +99,7 @@ jobs:
           sudo apt-get update
           sudo apt-get install -y ${{ matrix.packages }}
 
-      # Same reasoning as build-go above: upload the raw executable, built
+      # Same reasoning as build-tui above: upload the raw executable, built
       # with its final release name directly, no archive step.
       - name: Build gui
         env:
@@ -178,7 +180,7 @@ jobs:
             ${{ env.REGISTRY }}/${{ env.REGISTRY_OWNER }}/completed:latest
 
   release:
-    needs: [build-go, build-gui, build-web]
+    needs: [build-tui, build-gui, build-web]
     runs-on: ubuntu-latest
     steps:
       - uses: actions/download-artifact@v3