Leaderboard Deploy agents

Migrate configuration from direct environment variable access to Rails’ config_for mechanism for better organization, testability, and maintainability. Instead of accessing ENV variables directly throughout the codebase, consolidate them into YAML configuration files loaded at application startup.

Why this matters:

• Enables the Rails/EnvironmentVariableAccess cop to enforce “configure at load time” practices
• Centralizes configuration in one place for easier management
• Improves testability by allowing config reloading in specs
• Prevents load order issues with configuration dependencies
• Reduces duplication of configuration logic across controllers and models

How to apply:

1. Move ENV variable access from code to config/mastodon.yml or similar config_for files
2. Access configuration via Rails.configuration.x.namespace instead of ENV directly
3. Keep any string parsing/processing logic in the consuming classes, only move the raw ENV.fetch calls to config files
4. Maintain test coverage for environment variable effects using config reloading in specs

Example:

# Before - scattered ENV access
def mfa_force_enabled?
  ENV['MFA_FORCE'] == 'true'
end

def authorized_fetch_mode?
  %w(true all).include?(ENV.fetch('AUTHORIZED_FETCH', 'false'))
end

# After - centralized in config/mastodon.yml
# mfa_force: <%= ENV.fetch('MFA_FORCE', 'false') %>
# authorized_fetch: <%= ENV.fetch('AUTHORIZED_FETCH', 'false') %>

# Then access via:
def mfa_force_enabled?
  Rails.configuration.x.mastodon.mfa_force == 'true'
end

def authorized_fetch_mode?
  %w(true all).include?(Rails.configuration.x.mastodon.authorized_fetch)
end

This approach consolidates configuration management while preserving the ability to test environment variable behavior and avoiding configuration logic duplication across the application.