Unfreeze bundler for Dependabot only

[lortza]

This PR...

Conditionally unfreezes bundler in CI only when Dependabot is the author. This preserves frozen mode for regular PRs (catching real dependency mismatches) while allowing Dependabot's updates to proceed.

Why

Before Bundler 4 (Bundler 2–3)

In bundler 2–3, the frozen mode was opt-in via bundle install --frozen. In CI environments, it wasn't the default behavior. Dependabot could:

• Update Gemfile (e.g., bump standard gem)
• Run bundle install (which would regenerate Gemfile.lock)
• Commit both files
• CI would run with the new lockfile

No frozen mode conflicts because bundler would happily resolve and update the lockfile.

After Bundler 4 (Current Behavior)

Bundler 4 now defaults to frozen mode in CI-like environments. The key insight from your bundler 4.0.3 footer in the Gemfile.lock:

• Bundler 4 auto-detects CI environments (via CI=true env var or similar)
• When detected, it automatically enables frozen mode without explicit flags
• Frozen mode prevents Gemfile.lock modification, even if Gemfile changed

This breaks Dependabot's workflow:

• Dependabot updates Gemfile (e.g., standard 1.54.0 → 1.55.0)
• Dependabot also updates Gemfile.lock
• But when the CI workflow runs, bundler 4 sees both files and enforces a match
• If they don't match perfectly (due to transitive dependency differences), frozen mode rejects it

Why This Matters for Dependabot

Dependabot updates lockfiles, but it may not account for every transitive dependency change that bundler 4 would compute. Bundler 4's stricter frozen mode catches this discrepancy and fails rather than updating.