Chore: drop the stale EOLRails brakeman ignore after the Rails 8.1 upgrade lands

Context

PR #7108 added an EOLRails entry (fingerprint 21ab0fe00fdd5899ffc405cff75aadb91b805ee996a614f7e27b08a287e9062d) to config/brakeman.ignore to unblock CI. Brakeman had started failing on every branch with:

Check: EOLRails
Message: Support for Rails 8.0.5.1 ends on 2026-10-07

That ignore was the right call to stop the bleeding, but it is scoped more broadly than it looks.

The problem

The brakeman fingerprint for EOLRails does not hash the warning message — only the check/file/warning code. Verified locally by editing Gemfile.lock from rails (8.0.5.1) to rails (8.0.9): same fingerprint 21ab0fe0…, different message.

That is convenient today (dependabot Rails patch bumps won't re-break CI), but it means the entry will also silence the next EOL warning — including the Rails 8.1 one — so we'd lose the signal without noticing.

What to do

Once the Rails 8.1 upgrade lands (#7131 bumps rails to 8.1.3.1; #7019 is the broader upgrade):

• Remove the EOLRails entry from config/brakeman.ignore
• Run bundle exec brakeman and confirm it passes with the entry gone
• If a new EOL warning does appear for the upgraded version, re-add it with a note naming the target Rails version and its EOL date, so the next reader knows what the ignore is holding back

Only the EOLRails entry should be touched — the Dynamic Render Path entry for app/controllers/static_controller.rb is unrelated and should stay.

After Rails 8.1 lands, inspect the EOLRails entry in config/brakeman.ignore and leave the unrelated Dynamic Render Path entry unchanged. Run bundle exec brakeman and confirm the scan passes without the EOLRails entry; if the upgraded Rails version raises a new EOL warning, follow the issue's note and version/date requirements.