Remove the ratelimiting_include_plan_info flag

What does this MR do and why?

Removes the ratelimiting_include_plan_info feature flag.

It was a derisk gate so the plan facts (requester_plan, target_namespace_plan, target_root_namespace_id) could be switched on and watched before any throttle flag moved. The comment on the method it gated said as much: "Short lived: remove it once the facts are enabled." The facts have been enabled on GitLab.com since 22 September, so the gate has no job left.

Closes gitlab-com/gl-infra/production-engineering#29909.

Evidence the facts are on

Measured on gprd over 2026-09-28 05:20 to 05:50 UTC: the four Free plan rules evaluate at 2,250 to 2,870 per second each. A plan rule cannot match without the plan facts, so they are being emitted.

The part worth reviewing

FlagPolicy.plan_facts_enabled? was two conditions:

gitlab_com? && ::Feature.enabled?(:ratelimiting_include_plan_info, ...)

Removing the flag keeps the gitlab_com? half. The guard in the EE ClassifiedRequest#identity_facts becomes flag_policy.gitlab_com? rather than being deleted. Dropping it entirely would resolve requester_plan and target_namespace_plan on self-managed, where those plans do not exist, on every request.

Test plan

No new test. The behaviour that matters after the flag is gone is "no plan facts off GitLab.com", and the when not on GitLab.com context in the EE classified request spec already asserts all three keys are absent and that no tier is resolved.

Two spec blocks were removed because they tested the flag itself: the .plan_facts_enabled? describe in the flag policy spec, and the flag-off context in the EE classified request spec.

Green locally: 40 examples in ee/spec/lib/ee/gitlab/rack_attack/labkit_rate_limit/, 24 in ee/spec/lib/gitlab/rate_limit/, 0 failures. RuboCop clean.

After this deploys

The flag still exists in Flipper on GitLab.com and needs removing with Feature.remove once this is out. That is the last item on the issue.