Add Buildkite CI pipeline (Sorbet, Rubocop, tests)

[dduugg]

Summary

Adds a Buildkite pipeline that runs the same checks as our current GitHub Actions CI — Sorbet, Rubocop, and the minitest suite — bringing this repo onto Gusto's standard CI tool.

Why

While investigating why CI didn't appear on #73, the root cause turned out to be that the dependabot-tapioca workflow pushes the regenerated-RBI commit using the default GITHUB_TOKEN. GitHub Actions intentionally ignores pushes made with GITHUB_TOKEN (a recursion guard), so the RBI commit becomes the PR HEAD with no CI status — making it look like nothing ran (and hiding a real Rubocop failure on that PR).

Buildkite isn't subject to that guard: it builds commits via its GitHub webhook integration regardless of who pushed them. So moving CI to Buildkite fixes the re-trigger gap inherently — no GitHub App token or PAT needed.

What's included

• .buildkite/pipeline.yml — :sorbet: (srb tc), :rubocop:, and :minitest: (rake test) across a Ruby 3.3 / 3.4 / 4.0 matrix (matches the gemspec's >= 3.3 and the prior shared-config matrix). Each step runs via the docker-compose#v5.6.0 plugin.
• .buildkite/docker-compose.yml — builds Dockerfile.test, passing RUBY_VERSION (default 3.4, overridden per matrix entry) and forwarding the standard BUILDKITE_* env vars.
• Dockerfile.test — ruby:${RUBY_VERSION} base; installs ripgrep (packwerk needs it); pins Bundler to 4.0.7 to match Gemfile.lock's BUNDLED WITH; layer-caches the bundle. Gems install from rubygems.org.
• .github/workflows/dependabot-tapioca.yml — simplified back to a plain git push (the inline srb tc workaround is no longer needed, since Buildkite now runs the full suite against the RBI commit).

Gem publishing is intentionally not moved here — it stays in cd.yml. Moving it would require publish credentials available only on dedicated agents.

Verification (local)

Built Dockerfile.test for Ruby 3.4 and ran each command in-container:

• bundle exec rake test → 88 runs, 0 failures
• bundle exec srb tc → No errors
• bundle exec rubocop → 67 files, no offenses

All three YAML files parse.

Follow-up (requires Buildkite-org admin — not in this PR)

1. Create the Buildkite pipeline in Gusto's open-source Buildkite org — https://buildkite.com/gusto-open-source — pointing at this repo, with buildkite-agent pipeline upload .buildkite/pipeline.yml as the bootstrap step. (This repo is public, so it belongs in the dedicated gusto-open-source org, not the main internal Gusto org.)
2. Grant that org's agents clone access to this public repo and wire up the GitHub webhook.
3. Once Buildkite is green, retire .github/workflows/ci.yml and update branch-protection required checks from the Actions jobs to the Buildkite check.

Open questions for reviewers

• Keep ci.yml running in parallel during the transition (suggested), or remove it in this PR?
• Move gem publishing to Buildkite as well, or leave it on Actions?