ci: attach cot-cli binaries to releases

[alloutflo]

Related issue or discussion

Fixes #590.

Description

Build and attach cot-cli binaries when a cot-cli-v… GitHub release is created.

• Add a six-target matrix for Linux GNU, macOS, and Windows across x86_64 and ARM64.
• Start the build when release-plz creates the draft release, so the binaries are ready before publication.
• Use cross for Linux ARM64 and the standard upload action's native archive defaults: .tar.gz on Unix and .zip on Windows.
• Include the Apache 2.0 and MIT license texts in every archive and publish a SHA-256 checksum for every archive.
• Add cargo-binstall metadata whose tag, target, archive suffix, and internal binary path match those uploaded assets.

Type of change

• Bug fix
• New feature
• Documentation
• Refactor / cleanup
• Performance improvement
• Other: release automation

Verification

• actionlint 1.7.12 on the new workflow and the complete workflow set
• Repository-pinned yamlfmt 0.21.0 on the new workflow and the complete workflow set
• Verified the pinned taiki-e/upload-rust-binary-action@v1.30.2 inputs for additional archive files and SHA-256 output
• Parsed the updated Cargo manifest and expanded all six cargo-binstall URLs
• Simulated archive names and contents: four cot-cli-<target>.tar.gz archives containing cot, and two .zip archives containing cot.exe
• Resolved every referenced action tag against its upstream repository
• git diff --check

A full Rust cross-build was not run locally because the installed toolchain predates the workspace's Rust 1.94 requirement and local disk space was constrained. The remaining integration risk is the first real six-target release build, especially Windows ARM64; action/YAML/metadata wiring is validated above.

Checklist

• I've read the contributing guide
• Tests pass locally (just test-all) — no Rust source changed; see the toolchain limitation above
• Code passes clippy (just clippy) — no Rust source changed
• Code is properly formatted (repository yamlfmt)
• New tests added — release workflow validated statically; no unit-testable Rust behavior added
• Documentation updated where applicable (cargo-binstall package metadata)

AI disclosure: I used an AI coding assistant to inspect the release-plz and existing workflow conventions, implement this release matrix and cargo-binstall mapping, and run the static/semantic checks above. I reviewed the final workflow and understand the remaining first-cross-build risk before submitting.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
rust	90.21% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alloutflo]

Maintainer handoff: the fork’s Rust CI run completed the build/test and coverage-generation work; its only failing step is the final Codecov upload because CODECOV_TOKEN is empty on the fork (Token required - not valid tokenless upload). On the current cleanup-only head, pre-commit.ci and the upstream labeler are green; the Codecov report on the immediately preceding code-equivalent head states that all modified coverable lines are covered. There are no review threads or contributor-side failures. Four upstream Actions runs are still action_required with 0 jobs, so the remaining step is maintainer workflow approval and review.

[Copilot]

Pull request overview

Adds automated cross-platform cot-cli release binaries and cargo-binstall support, addressing #590.

Changes:

• Builds and uploads binaries for six Linux, macOS, and Windows targets.
• Configures cargo-binstall to locate the release archives and binaries.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
.github/workflows/release-binaries.yml	Adds the release-triggered build and upload matrix.
cot-cli/Cargo.toml	Adds cargo-binstall release metadata.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[seqre]

Thank you for your work and welcome to Cot's community!

Overall, it looks good and needs only few changes for it to be good enough for merging. Specifically, apart from code comments, I'd like for sha256sums be available for each artifact for integrity verification and for license files to be included in the archives (licenses ask that their text accompany distributed copies).

While not required, if you want to go extra steps, please consider the following:

• build provenance attestation (eg. GitHub's official)
• including README.md and CHANGELOG.md into archives
• generating and including shell completions

ripgrep's release system is one good example of such actions

[seqre]

To increase portability of binaries, I'd choose to use ubuntu-22.04 for older glibc or compiling musl version (or both). What do you think @cot-rs/maintainers?

[alloutflo]

Agreed that the glibc baseline should be intentional. I have left this matrix unchanged for now because ubuntu-22.04 for the existing GNU targets, adding musl targets, and shipping both define different artifact sets. @cot-rs/maintainers, which of those should this PR adopt? I can update the matrix and cargo-binstall mapping once that choice is confirmed.

[alloutflo]

Implemented the requested release-artifact changes in 898a159: builds now start on the created release event, both license texts are included in each archive, and the action publishes SHA-256 checksum files. actionlint 1.7.12, the repository's yamlfmt 0.21.0 configuration, and git diff --check pass. I answered and resolved the event thread; the Linux baseline/musl thread remains open pending the maintainers' choice between Ubuntu 22.04 GNU, musl, or both. The optional attestation, README/CHANGELOG, and completion additions are intentionally outside this focused update.