Remove rate_limiting_rule_bypass_header feature flag

What does this MR do

Removes the rate_limiting_rule_bypass_header feature flag and its related code, making the new bypass-header traffic visibility behavior permanent. This MR:

• Removes the Feature.enabled? check and legacy short-circuit branch from Gitlab::ApplicationRateLimiter#throttled_request? in lib/gitlab/application_rate_limiter.rb
• Deletes the flag's YAML definition in config/feature_flags/ops/rate_limiting_rule_bypass_header.yml
• Removes now-obsolete flag-gated test branches from three spec files that tested the old disabled-flag behavior

Why

The flag gated whether trusted internal bypass-header traffic (requests carrying GITLAB_THROTTLE_BYPASS_HEADER) was routed through labkit's rate limiter. When disabled, the old code short-circuited rate-limit checks for bypass traffic entirely, making bypass volume invisible with no metrics or counters. When enabled, bypass traffic flows through labkit's rule evaluation and matches a synthetic :skip rule, incrementing the gitlab_labkit_rate_limiter_calls_total{action="skip"} Prometheus counter while still never being blocked.

The flag was enabled on staging 2026-08-17 and rolled out to production in steps (5%, 10%, 25%, 50%, 75%, 100%) from 2026-08-17 to 2026-08-18, reaching 100% on 2026-08-18. After reviewing bypass-traffic metrics over a 24-hour window, the behavior was confirmed healthy and stable with no Redis or performance regressions and no cardinality issues.

Since the flag's default_enabled was false in its YAML definition, self-managed instances never received this visibility improvement until now. Removing the flag makes the behavior permanent for all instances, including self-managed. One accepted tradeoff: bypass-header requests now go through labkit's key-registration and settings-lookup checks instead of skipping them. This was already evaluated with the rate-limiting maintainers during rollout and judged acceptable, since those checks validate the rate limiter's configuration rather than something unique to bypass traffic.

Upgrade compatibility

During a rolling deploy, nodes running the old code still call Feature.enabled?(:rate_limiting_rule_bypass_header, ..., type: :ops) even after this MR deletes the flag's YAML definition. This is safe:

• Feature.enabled?'s YAML-definition check (Feature.check_feature_flags_definition! in lib/feature.rb) only raises when the flag is undefined in dev/test environments (Gitlab.dev_or_test_env?). In production it is a no-op, so the missing YAML does not error or change behavior on old nodes.
• Old nodes fall through to reading the flag's persisted Flipper gate state, which is still 100% enabled in production from the completed rollout (2026-08-18). That persisted state is untouched by this MR; it is only cleared afterward by the /chatops feature delete step in the rollout issue's Cleanup section, run once this MR is deployed.
• So for the duration of the rolling upgrade, old nodes evaluate the flag as enabled and take the same labkit-routed path that new nodes take unconditionally. There is no behavioral divergence between old and new nodes at any point.

References

• Rollout issue: [FF] `rate_limiting_rule_bypass_header` -- Bypa... (#613319 - closed)
• Introducing MR: Track bypass header traffic through labkit metrics (!249596 - merged)