Add tag-triggered gem release workflow and gate it on CI

[atongen]

What's next

This PR is the first step toward fully automated releases: pushing a vX.Y.Z
tag on main runs CI, publishes the gem to RubyGems, and creates a GitHub
release with notes from CHANGELOG.md.

Follow-up work:

• Repo settings (admin, no code):
  • Branch ruleset on main: PR + 1 approval from @DripEmail/developers
    (via CODEOWNERS), required ci-ok check, no bypass.
  • Tag rulesets for v*: only @DripEmail/developers can create release
    tags; nobody can move or delete them.
  • release environment limited to v* tags.
  • RubyGems trusted publisher for this workflow (no API key stored in GitHub).
• Gem contents: build the gem from an explicit file list instead of
  git ls-files, so it stops shipping tests and repo tooling.
• Release tooling: rake release:prepare[VERSION] (bump version, roll
  the changelog) and rake release:tag (pre-flight checks, then tag and push),
  so any team member can cut a release safely.
• Release job: explicit, re-runnable build/publish steps; visible compare
  link in release notes; prerelease support (vX.Y.Z.rcN); a dry-run mode.
• First automated release: a 3.5.1.rc1 prerelease to exercise the
  pipeline end to end, then 3.5.1. Backfill the v3.5.0 GitHub release and
  update the README release instructions.

[stevedrip]

I'm still on the side of dropping support for this gem entirely, but I would want to upgrade it first and cut a new release. This doesn't hinder that, and if we had some upgrade path to a dry swagger implementation that'd be a reasonable compromise.

No matter where we go, I see this PR as a step forward.