ci: trigger the release on an unpublished version, fail on partial publish

[jaemk]

Two defects in the release pipeline, both of which have already fired.

The trigger could be silently lost

release.yml published only when the head commit message started with release:. Squash-merging a release PR replaces the commit message with the PR title, so the prefix is discarded and the workflow skips. It still reports success, having done nothing. That happened on #302: rc.10 was merged and nothing published.

The guard now keys off the actual signal, in a check job: publish when the root crate's version is not on crates.io. The commit message and the merge strategy no longer matter.

Verified against the live index:

3.0.0-rc.10 -> should_publish=false   (already published)
3.0.0-rc.9  -> should_publish=false
3.0.0       -> should_publish=true

A network or API failure during the check fails the job rather than resolving to "nothing to publish", so a transient error cannot silently skip a release.

A partial publish reported success

publish.sh exited 0 if any crate published. The rc.9 run shows the consequence:

error: crate cached_proc_macro_types@3.0.0-rc.8 already exists on crates.io index
Failed to publish crate in cached_proc_macro_types
error: crate cached_proc_macro@3.0.0-rc.8 already exists on crates.io index
Failed to publish crate in cached_proc_macro

Two of three crates "failed", the root published, the script exited 0. v3.0.0-rc.9 still has a git tag with no GitHub release because the tagging step then died partway.

publish.sh now separates the two cases: a version already on the index is a benign skip that keeps re-runs idempotent, and any other failure fails the release. Publishing the root crate while a bumped subcrate failed would put cached on the index depending on a cached_proc_macro* version that does not exist.

Notes

• Merging this does not publish anything: Cargo.toml is at 3.0.0-rc.10, which is already on crates.io, so should_publish is false.
• The tagging step now runs whenever publishing did not fail, so a release that published but died before tagging picks up its tags on a re-run.
• workflow_dispatch is unchanged and still bypasses the check, which is what recovered rc.10.