ci: a rubocop release can redden required lint on main with no PR at fault

[ivndev001]

Steps to reproduce

1. Wait for rubocop to publish a release that adds or tightens a cop.
2. Open any PR, or push to main.
3. lint (rubocop) goes red on code nobody in the PR touched.

Expected

A required check goes red because of the change under review.

Actual

lint (rubocop) can go red on main with no PR at fault, because two settings compose:

• .rubocop.yml: AllCops.NewCops: enable — every new cop in a release is active immediately.
• .gitignore:5: Gemfile.lock is gitignored, so the lint job resolves rubocop fresh on every run and picks up each new release.

This already happened. The CHANGELOG entry for 1.7.4 records it:

Gemfile.lock is gitignored on purpose, so the lint job resolves rubocop fresh every run and inherits each release's new cops. 1.90 added Style/DirectiveScope and tightened Layout/ExtraSpacing, putting 14 offenses on main that no PR introduced.

PR #450 was the cleanup. That is a repo-wide red gate arriving on an ecosystem release, with no local change and no warning.

It matters more now than it did then: lint (rubocop) became a required check on the main-protection ruleset on 2026-09-01, so this failure mode now blocks every merge on the repo until someone clears it by hand.

Version

origin/main at 8f7232d.

Suggested fix

There is a real trade here and it should be decided rather than defaulted:

• Pin rubocop to an explicit version in the Gemfile and bump it deliberately. Turns a surprise red into a scheduled PR. Costs a periodic bump; NewCops: enable keeps its meaning at the moment of the bump instead of at an arbitrary release.
• Keep floating and accept the interrupt. Cheapest to leave alone, and the current behaviour. Now that lint is required, the interrupt blocks all merges rather than one job.
• Keep floating but stop the bleed — e.g. pin only the cop set via NewCops: disable plus explicit enables. Preserves fresh resolution while making new cops opt-in.

Whichever is chosen, record the reasoning next to the setting. The current arrangement reads as deliberate (the CHANGELOG explains the gitignore) but predates lint being required, and that is the fact that changed.

Note for whoever fixes it: PR #450's four spacing offenses were repaired by hand rather than by rubocop's autocorrect, because -a deleted alignment instead of fixing it and left Stats::FAST_QUERIES half-aligned. There is no sanctioned autocorrect path here.