Added an explicit bundle install step so release-gem will work, I didn't realize bundler-cache was the only way to get setup-ruby to run bundle install 😬

@connorshea Thanks for opening this PR. It prompted me to do a full GitHub Actions hardening pass on the repo, see #83.

I was wondering about cache-poisoning, and I'm not sure that it's an attack vector for this workflow. GitHub Actions caches are isolated by git ref. A cache created by a pull request lives in the refs/pull/<n>/merge scope and, per the caching docs, can only be restored by re-runs of that same PR. It cannot be restored by the base branch or by other PRs.

This push_gem.yml runs on a tag push, so it only ever restores from its own tag ref (normally empty) and the default branch. Nothing a fork or PR does can write into the scope the release build reads. Writing into the default branch's cache requires running a workflow on the default branch, which means merge access, and at that point the release workflow itself is editable.

So instead of turning caching off (which also needs the extra bundle install step and slows the release slightly), I think I'd rather keep bundler-cache: true and add an inline # zizmor: ignore[cache-poisoning] note that records this reasoning, as part of the hardening branch. Does that sound right? Am I missing something?

I'm asking because I'd like to really understand this attack vector a bit better -- I have an agent skill to perform workflow hardening and I want to make sure it's doing the right thing.