chore: add public API snapshot check

[marandaneto]

💡 Motivation and Context

Add a generated public Ruby API snapshot so CI can detect accidental public API changes before release.

💚 How did you test it?

• bundle exec rubocop
• bundle exec rake public_api:check

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran pnpm changeset to generate a changeset file

[greptile-apps]

Comments Outside Diff (1)

1. .github/workflows/release.yml, line 199-203 (link)

   Shallow clone may fail git tag on COMMIT_HASH

   The publish job tags COMMIT_HASH (output from the version-bump job) in a shallow clone. With the default fetch-depth: 1, only the current HEAD of main is fetched. If any other commit lands on main in the window between version-bump completing and publish checking out, git tag -a "$NEW_VERSION" "$COMMIT_HASH" will fail with "fatal: not a valid object name" because COMMIT_HASH won't be present in the local repository. The original fetch-depth: 0 was presumably there to prevent exactly this. The check-changesets and version-bump jobs don't traverse history and are safe without it, but the publish job is the one that actually uses COMMIT_HASH to create the annotated tag.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: .github/workflows/release.yml
   Line: 199-203
   
   Comment:
   **Shallow clone may fail `git tag` on `COMMIT_HASH`**
   
   The `publish` job tags `COMMIT_HASH` (output from the `version-bump` job) in a shallow clone. With the default `fetch-depth: 1`, only the current HEAD of `main` is fetched. If any other commit lands on `main` in the window between `version-bump` completing and `publish` checking out, `git tag -a "$NEW_VERSION" "$COMMIT_HASH"` will fail with "fatal: not a valid object name" because `COMMIT_HASH` won't be present in the local repository. The original `fetch-depth: 0` was presumably there to prevent exactly this. The `check-changesets` and `version-bump` jobs don't traverse history and are safe without it, but the `publish` job is the one that actually uses `COMMIT_HASH` to create the annotated tag.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
.github/workflows/release.yml:199-203
**Shallow clone may fail `git tag` on `COMMIT_HASH`**

The `publish` job tags `COMMIT_HASH` (output from the `version-bump` job) in a shallow clone. With the default `fetch-depth: 1`, only the current HEAD of `main` is fetched. If any other commit lands on `main` in the window between `version-bump` completing and `publish` checking out, `git tag -a "$NEW_VERSION" "$COMMIT_HASH"` will fail with "fatal: not a valid object name" because `COMMIT_HASH` won't be present in the local repository. The original `fetch-depth: 0` was presumably there to prevent exactly this. The `check-changesets` and `version-bump` jobs don't traverse history and are safe without it, but the `publish` job is the one that actually uses `COMMIT_HASH` to create the annotated tag.

_{Reviews (1): Last reviewed commit: "chore: fix public API snapshot lint" | Re-trigger Greptile}