Fix the release workflow so a dispatch actually produces assets

[philipbjorge]

Addresses #43. Every Release run since v0.3.7 has failed, which is why v0.3.26 shipped with no assets and v0.3.27 is Windows-only. There are three independent causes; each is its own commit so you can take them separately.

1. One failed leg cancels the rest

The v0.3.26 run:

job	conclusion	steps executed
Build x86_64-pc-windows-msvc	failure	0
Build x86_64-unknown-linux-gnu	failure	0
Build aarch64-apple-darwin	cancelled	0
Build x86_64-apple-darwin	cancelled	0
Build aarch64-unknown-linux-gnu	cancelled	0
Upload Release Assets	skipped	—

Zero steps on the failed jobs means they never acquired a runner. Default fail-fast then cancelled the three healthy legs, and needs: build skipped the upload — so a runner-availability problem on two targets became a release with nothing attached.

fail-fast: false makes an unavailable runner cost one target instead of five. upload now runs on !cancelled() so a partial asset set still reaches the release, with an explicit guard that fails loudly if nothing built rather than silently publishing an empty release.

2. The dispatched tag is never actually used

workflow_dispatch takes no inputs, so:

• the build matrix compiles whatever ref the dispatch happened to use;
• softprops/action-gh-release falls back to github.ref for the target release, which is a branch ref whenever the workflow is dispatched from a branch rather than a tag;
• the publish job checks out that same ref, so cargo publish can package the branch instead of the tagged source.

This adds a required tag input, checks it out in both the build matrix and the publish job, and passes it to the release action explicitly.

3. The release matrix cannot get Blacksmith runners

The Windows and Linux legs request Blacksmith runners and failed without executing a step. The label is live — PR Check uses blacksmith-4vcpu-ubuntu-2404 successfully — but the release matrix requests three Blacksmith runners simultaneously and does not get them.

This moves the five release targets to GitHub-hosted runners. I want to be careful here because ADR 0001 is explicit about protecting the shared Blacksmith pool: this repository is public, so GitHub-hosted minutes are free, and a dispatch-only release that runs a few times a month then draws nothing from the shared pool. That serves the ADR's stated goal more completely than routing release builds through it. PR Check stays on Blacksmith, untouched.

If you would rather keep the release on Blacksmith, commits 1 and 2 stand on their own and are worth taking regardless — commit 1 alone would have given v0.3.26 its macOS assets.

Verification

actionlint passes clean on the result. I have not been able to execute the workflow against your runners, so the runner change in commit 3 is the one piece verified by reasoning rather than by a run.

[philipbjorge]

The red PR Check here is the pre-existing cargo fmt --check failure on master, not something this branch introduces — it fails on "Check formatting" for the trailing blank line in src/commands/initiatives.rs, the same failure master has had since 2026-08-05. This branch touches only .github/workflows/release.yml.

#46 includes the one-line fix, so this goes green once that lands (or if you would rather have it here instead, say the word and I will move it).

[esafak]

@Finesssee Please can we get this merged? CI is broken! Please consider adding collaborators to the project. I am tempted to fork it but I don't want to set up a competing crate.

[Finesssee]

I'm setting up circleCI to make it work rn and I would love some help a temp collaborator on this project

[esafak]

That's great. Assuming you are talking about moving from Blacksmith, could you remind us newcomers why you can't use Github CI? Feel free to add me as a maintainer. If you want I can restrict my attention to CI, or whatever.

For reference, I'm here because the macOS images are absent.