Add per-user rate limit to DELETE /groups/:id

What does this MR do and why?

Adds a per-user rate limit of 10 requests per minute to DELETE /api/:version/groups/:id. It is the same limit as the one added for project deletion in !263603 (merged), which this MR is stacked on.

The limit applies to every request to the endpoint, whether it schedules the group for deletion (the default) or uses permanently_remove. Even scheduling a deletion does synchronous work per request (a transaction, a group rename and a deletion schedule row), so a burst of requests pressures the primary database and PgBouncer. This is a per-user cap on request volume as defense-in-depth. It does not throttle the destroy work itself: for the default path, that is enqueued later by the adjourned-deletion cron, which already paces it.

The limit sits behind the group_and_project_delete_rate_limit feature flag (disabled by default), which is introduced in !263603 (merged) and shared with the project deletion limit.

The limit is fixed rather than an admin setting. It covers the REST endpoint only.

References

• Stacked on: !263603 (merged)
• Incident review: https://gitlab.com/gitlab-com/gl-infra/production/-/work_items/23245#note_4049141931
• Rollout issue: #635074
• WS9 endpoint rate-limit audit: https://gitlab.com/gitlab-org/gitlab/-/work_items/605332

Screenshots or screen recordings

Not applicable, no UI changes.

How to set up and validate locally

1. Enable the flag in a Rails console: Feature.enable(:group_and_project_delete_rate_limit)
2. In a Rails console, create 11 throwaway groups owned by a test user.
3. Send 11 DELETE /api/v4/groups/:id requests within a minute using that user's personal access token.
4. The 11th request returns 429 with a Retry-After: 60 header and RateLimit-Name: group_delete_api.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.