Stop a re-pushed tag from failing the release
Pushing the v1.5.6 tag twice fired every release workflow twice. The other four duplicates were cancelled, but the crates.io one went red with "crate sigit@1.5.6 already exists on crates.io index", even though that workflow already has a check meant to catch exactly this. The check asked crates.io with curl's default User-Agent, which crates.io answers with a 403. Since it used "curl -fsS", that read as a failure, the check concluded the version was unpublished, and cargo publish then walked into a version that was already there. Send a real User-Agent and branch on the status code, so an answer we do not understand stops the job instead of turning into that same confusing publish error. Group every release workflow by tag as well, so a duplicate cannot race the original. cancel-in-progress stays false on purpose: interrupting a half-finished upload is worse than letting the duplicate queue up and no-op against the already-published checks.