NameError in ActiveSupport::LoggerThreadSafeLevel after concurrent-ruby update

Context

A Rails application on an older 6.x or 7.0 line begins raising a NameError referencing an uninitialized constant inside ActiveSupport::LoggerThreadSafeLevel after a routine bundle update. The backtrace points to the first logging call or to boot, not to application code. The root cause is a transitive dependency shift: concurrent-ruby stopped requiring Ruby's logger standard library, and the affected Rails versions relied on that transitive require instead of declaring a direct dependency on the logger gem.

Constraints and uncertainty

The exact Rails releases that added an explicit logger dependency, and the precise concurrent-ruby version that removed the require, need confirmation from changelogs and gemspecs. Pinning concurrent-ruby may conflict with other gems' version requirements. Upgrading Rails to a line that depends on logger directly introduces its own compatibility work. Adding an explicit require "logger" in an initializer or Gemfile is a localized workaround but must remain until the Rails upgrade lands.

Questions

1. Which Rails release series first declared a direct dependency on the logger gem, making them immune to this transitive-require loss?
2. For a codebase that cannot upgrade Rails immediately, is pinning concurrent-ruby to a version that still requires logger a safe temporary measure, or does it risk downstream version conflicts?
3. Does placing require "logger" in config/initializers/logger_compat.rb reliably resolve the NameError across all load-order variations, or are there edge cases where the constant is still missing at the point ActiveSupport::LoggerThreadSafeLevel is evaluated?