Add release workflow for the Go CLI

[xxxxxxjun]

Summary

Automates CLI releases. Pushing a cli/X.Y.Z tag builds all four platforms, packages them, and attaches the archives to a draft release for review.

Closes #37

Two things the issue leaves ambiguous. I picked an answer for each so this could be implemented; say the word and I'll change either.

Asset names. The issue lists three unversioned files. I used actionbase_{version}_{os}_{arch} plus a windows_amd64 .zip, which is what the published cli/0.0.1 ships and what make build-all already names its output directories, so nothing needs renaming.

Tag form. cli/X.Y.Z, no v. A leading v is stripped if present, so cli/v1.0.0 works too. Stripping matters because the version reaches -X main.Version, and the CLI prepends its own v when printing --version, so a v-prefixed tag would report vv1.0.0.

Changes

• .github/workflows/release-cli.yml: builds and packages on tag pushes, on PRs touching this workflow or cli/Makefile, and on manual dispatch, publishing four archives plus checksums.txt. Only tag pushes reach the publish job, so PR runs keep a read-only token.
• cli/Makefile: new package target, so make package VERSION=1.0.0 reproduces the release artifacts locally. It depends on build-all, per the issue's "use the existing cli/Makefile".
• cli/README.md: rewrote the Release Guide, which told you to git tag -a v1.0.0. That tag has no cli/ prefix, so it wouldn't trigger the workflow at all.

Choices worth flagging:

• Publish refuses to touch an already-published release. --clobber deletes assets before uploading, and cli/0.0.1's hand-built assets aren't reproducible.
• The build asserts GOOS/GOARCH per binary, not only the version string. That string is identical across platforms, so nothing else would catch a darwin_amd64 binary inside the darwin_arm64 archive.
• No --generate-notes. .github/release.yml is repo-wide with no per-tag scoping, so notes on a cli/ tag would sweep in every server and engine PR since the last tag.
• concurrency: is grouped per ref, so distinct tags never contend. Cancelling a tag run mid-upload would leave a partial asset set, so cancel-in-progress is limited to pull requests.

Left alone deliberately:

• The install.sh sections of cli/README.md are byte-identical. There's no install.sh in the tree and I didn't want to decide whether it's still planned, so I put a two-line note above them rather than editing them.
• RELEASES.md line 124 says CLI binaries ship via Releases but documents no procedure, and linux/arm64 has never shipped. Both look like follow-ups.

How to Test

The build job runs on this PR, since its trigger paths include the workflow file.

For the publish half, I ran the pipeline on my fork:

• Happy path. Five assets on a draft release. I downloaded them, shasum -a 256 -c checksums.txt passed on all four archives, and the darwin_arm64 binary reported v0.0.0-rc.1.
• Same tag pushed twice, first and second. The second run found the existing draft and replaced its assets; it never calls gh release create, so no duplicate release appears.
• Guard against overwriting a published release (attempt 2, red on purpose). Fails at Create draft release if absent with cli/0.0.0-rc.3 is already published; refusing to overwrite its assets, and Upload assets never runs.

Locally, cd cli && make package VERSION=1.0.0 produces the same five files.