Release automatically when the gemspec version changes

[dduugg]

Summary

Fixes #23. Releases now happen when singed.gemspec's version changes, the way the rubyatscale gems that use shared-config's cd.yml release. This is the approach #78 had at 6e0947c, before it moved to release-please. It's here so releases work while #78 waits for approvals; #78 can replace it once it lands.

push_gem.yml already published through RubyGems trusted publishing with rubygems/release-gem, but only by hand, and it has never run. It now runs after CI Test passes on main, and publishes only when the gemspec's version isn't on RubyGems yet, so bumping the version is the release. It can still be dispatched from main to retry, and it skips whatever's already done. A dispatch doesn't wait for CI, so it's meant for when main is green.

• check job: only lets a push to this repo's main through, since a fork's pull request can come from a branch named main. It reads singed.gemspec through the API at the tested SHA instead of checking it out and evaluating it, so no code from the triggering commit runs in this privileged context. It then asks RubyGems whether the version exists and GitHub whether it has a release. The RubyGems lookup retries on transient errors, since the job runs after every green push to main, not only after a version bump.
• release job: rake release pushes the current branch along with the tag, so the job checks out main itself rather than a detached HEAD. It first confirms main is still the commit CI tested. No bundler cache, since it publishes. The checkout doesn't persist credentials: release-gem v1.4.1 puts the token in git's credential cache for the tag push.
• github_release job: creates the GitHub release in a separate job, so a retry can still create it after the gem has shipped. Versions with a letter in them, which RubyGems treats as prereleases, get --prerelease.
• notify_on_failure: posts to Slack when any job fails, like cd.yml.

The workflow's filename and the rubygems.org environment stay as they are, since the trusted publisher on RubyGems.org is registered against them.

These are #78's four commits cherry-picked onto main. The resulting push_gem.yml matches 6e0947c's except for three action pins, which keep main's newer versions (harden-runner v2.21.1, checkout v7.0.1, setup-ruby v1.325.0). The first commit's message drops two bullets that #80 and #81 already delivered. The last four commits are follow-ups from review, so the file now also differs from 6e0947c's in those.

Test plan

• zizmor 1.30.1 with online audits: no findings.
• actionlint: clean.
• Gemfile.lock already lists x86_64-linux, and setup-ruby installs the BUNDLED WITH version, so bundle install shouldn't dirty the tree before rake release (the failure described in Automate releasing #23).
• Fresh Eyes local review: three minor notes, none blocking. A second pass after the follow-up commits found nothing blocking either: its one minor finding doesn't hold, because release-gem fetches tags before rake release, so a retry after a tag push skips the tag and pushes the gem.
  • A failed gh api fetch would stop the step with gh's own error, since the default shell runs bash -e.
  • If main moves between check and release, only the newer version is released; the earlier run aborts on purpose and posts to Slack.
  • --verify-tag fails rather than creating a release without a tag.
• CI passes on this PR, and CodeQL and zizmor report nothing. The release path itself only runs after a version bump merges to main.