Constrain git gem to < 6 when auto-generating Gemfile

What does this MR do?

Pins the git gem to < 6 in the Gemfile that the danger-review job auto-generates when a project has no Gemfile of its own.

Why?

git 6.0.0 (released 2026-10-28) removed the Git::Base constant. Its CHANGELOG says:

The Git::Base constant no longer exists, so is_a?(Git::Base) checks and monkeypatches of Git::Base raise NameError.

danger 9.6.1 (the latest release) depends on git >= 1.13 with no upper bound, and danger/scm_source/git_repo.rb:209 still references Git::Base on load. As a result, every danger-review job without its own Gemfile now resolves git 6.0.0 and crashes before Danger runs:

bundler: failed to load command: danger (/usr/local/bundle/bin/danger)
/usr/local/bundle/gems/danger-9.6.1/lib/danger/scm_source/git_repo.rb:209:in `<top (required)>': uninitialized constant Git::Base (NameError)

Example failure: https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/jobs/17562436289

This uses the same approach as the earlier git < 5.0.0 pin in !22 (merged), which was reverted in !23 (merged) once danger 9.6.1 added git v5 support. git 5.x still provides a Git::Base compatibility shim, which danger 9.6.1 handles.

Projects that ship their own Gemfile are not affected by this change.

How was this tested?

I ran the template's Gemfile, bundle install and bundle exec danger --version steps locally with Ruby 3.3.12 (the job image is ruby:3.3):

Setup	git resolved	bundle exec danger --version
Current template, gitlab-dangerfiles 4.7.0	6.0.0	❌ uninitialized constant Git::Base (NameError)
This MR, gitlab-dangerfiles 4.7.0	5.7.1	✅ 9.6.1
This MR, gitlab_dangerfiles_version empty (resolves 4.14.0)	5.7.1	✅ 9.6.1

Follow-up

• Remove the pin once danger releases a version compatible with git v6.
• After merging, the component needs a new release so consumers pinned to a tagged version (e.g. danger-review@2.1.0) can pick up the fix.

🤖 Generated with Claude Code