fix(ci): pin git gem to unblock danger-review

Summary

The danger-review CI component (v2.1.0) auto-generates a Gemfile at job runtime via bundle add gitlab-dangerfiles when the repo has none. That resolves against latest upstream gems, which currently means danger-9.6.0 + git-5.0.0 — an incompatible pair:

danger-9.6.0/lib/danger/scm_source/git_repo.rb:196:in `<module:Git>':
  Base is not a class (TypeError)
git-5.0.0/lib/git.rb:133:
  previous definition of Base was here

git v5.0.0 changed Git::Base (previously a class), and danger still tries to reopen it as a class, so every MR pipeline's danger-review job fails on load.

Example failing job: !3632 pipeline 2712437577.

Fix

The component's before_script short-circuits its auto-bundle add when a Gemfile exists in the repo:

[[ -f "Gemfile" ]] || (bundle init && bundle add gitlab-dangerfiles --version "...")

This MR adds a minimal Gemfile that pins git < 5.0.0. That's the same escape hatch gitlab-org/gitlab uses (via its own bundle_install_script before_script override) — they don't hit this bug because their committed Gemfile.lock already pins compatible versions.

No Gemfile.lock here on purpose: bundler still resolves at runtime, just within the < 5.0.0 constraint. That keeps Renovate out of it and lets us delete this file entirely once danger releases a version compatible with git v5 (or caps its git dep in its gemspec).

A companion upstream fix against gitlab-org/components/danger-review will follow so other component consumers without a Gemfile aren't affected.

Test plan

• danger-review job passes on this MR's pipeline (it should now install our two-gem Gemfile instead of auto-adding danger + git-5.0.0)