build: commit Gemfile.lock and add dependabot

[jbutte]

Resolution was fresh on every run, so two checkouts a week apart could run different rspec-core or redis versions, and dependency drift never showed up in a diff. Committing the lock pins the default resolution.

The matrix still resolves past it — each leg pins its own combination through the gemspec env hooks — so build.yml drops the lock before installing. I confirmed that without this, bundler re-resolves anyway and silently rewrites the lock every run (rspec-core 3.13.6 → 3.12.3), so the explicit rm just makes the existing behaviour honest.

Lint keeps the lock and fails if bundler had to rewrite it, which catches a version bump that forgot to regenerate it. Worth noting: because the Gemfile uses gemspec, the lock records rspecq's own version, so a version bump must include the regenerated lock.

Dependabot covers both ecosystems — github-actions to move the SHA pins, which otherwise freeze permanently, and bundler, which only becomes useful now that there's a lockfile to bump.

⚠️ Do not add bundle config set frozen true later. Frozen mode plus env-pinned gemspec deps breaks the matrix outright — I hit exactly that while testing.

refs DE-1818

Test plan

• Lint clean, suite green with the lock committed
• Verified bundler rewrites the lock when env hooks pin different versions
• Lint's Gemfile.lock is up to date check passes on CI — confirms setup-ruby installs the bundler from BUNDLED WITH rather than churning the line
• All 5 matrix legs green

🤖 Generated with Claude Code