feat: automated releases — install ct from the GitHub Releases page

[2000game]

Automated releases so ct installs straight from the GitHub Releases page — no clone + npm run build.

Part of #1.

Why

Today, install = clone → npm ci → npm run build → npm link. We want: open the Releases page (or run one command / brew install), get a working ct binary.

Scope

• Tag-triggered GitHub Release — done (PR feat: tag-triggered releases — installable ct tarball on the GitHub Releases page (#9) #44): pushing v* runs the CI gate and publishes an npm-pack tarball as a GitHub Release. Remaining below builds on this.
• Automated versioning + changelog on merge to main (no manual tag push), driven by our conventional-commit PR titles (consistent with the rest of eqrm, which already uses semantic-release).
• Build standalone, dependency-free binaries and attach them as release assets:
  • macOS arm64 + x64 (primary — the tool targets Mac/Unix)
  • optionally linux x64
• Documented one-liner install from the latest release (download binary → chmod +x → onto PATH), added to the README.

Approach (decided 2026-07-09)

• Release automation: semantic-release — org standard, and our conventional-commit PR titles already feed it.
• Binary packaging: bun build --compile with a target matrix (bun-darwin-arm64, bun-darwin-x64, optionally bun-linux-x64). Viable because ct-cli has zero native modules — runtime deps are pure JS (commander, jiti, openapi-fetch, picocolors) and the Keychain is driven via the security CLI. Fallback if Bun misbehaves: @yao-pkg/pkg. The risky path is jiti's runtime TS transpilation of user configs — so CI must smoke-test each compiled binary with ct --help and a ct plan/config-load against a fixture .config.ts (exercises jiti inside the binary), not just --help.
• Extend the existing .github/workflows/release.yml (tag-triggered, PR feat: tag-triggered releases — installable ct tarball on the GitHub Releases page (#9) #44): semantic-release on push to main creates the tag/changelog; the binary matrix runs in the release job and uploads assets alongside the tarball.
• npm publish: no — repo is private; GitHub Releases only. eqrm/ct-structure consumes ct-cli as a git dependency or the released binary; revisit private GitHub Packages npm only if that chafes.

Stretch / follow-up

• Homebrew tap — auto-update a formula in eqrm/homebrew-tap so brew install eqrm/tap/ct works (the Notion design's distribution plan). Can be split into its own issue.

Acceptance criteria

• Merging a feat:/fix: PR to main produces a new GitHub Release (version bump + changelog) with no manual steps.
• The release carries downloadable macOS binaries (arm64 + x64) that run ct --help on a clean machine with no Node installed.
• README documents the install-from-Releases one-liner.
• (Stretch) brew install eqrm/tap/ct works.

[2000game]

First slice merged: tag-triggered GitHub Release with an npm-installable tarball (push a v0.1.0-style tag to cut a release). Remaining scope for this issue: standalone no-Node binaries (SEA/pkg/bun --compile), auto-versioning on merge to main, optional Homebrew tap.