Constrain git gem to < 5.0.0 when auto-generating Gemfile

Summary

Consumers of this component that don't commit a repo-level Gemfile currently have their danger-review job break at gem-load time:

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 gem v5.0.0 changed Git::Base (previously a class), and danger still opens module Git and does class Base ..., which raises TypeError at load. Every consumer whose bundle install resolves unconstrained hits this — the auto-generated bundle add gitlab-dangerfiles in template.yml pulls latest danger + latest git together.

Real-world example that hit us in gitlab-org/cli: failing job 15578441366. Companion downstream workaround at gitlab-org/cli!3637 (merged) (adds a project-level Gemfile with the same pin) is removable once this ships.

Fix

Directly pin git < 5.0.0 in the auto-generated Gemfile path:

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

• Consumers that commit their own Gemfile are unaffected — the auto-add branch is gated on [[ -f "Gemfile" ]].
• No new input: the constraint is a temporary compatibility workaround, not a knob consumers should need to reason about. A comment in the template explains why it's there and when to remove it.
• Remove this pin once danger publishes a version compatible with git v5 (or caps its git dep in its gemspec).

Test plan

• Component pipeline passes.
• After merge, retry a danger-review job in a consumer repo without a Gemfile (e.g. re-run gitlab-org/cli!3632's pipeline) and confirm it now installs git < 5.0.0.