Add feature flag support for hand raise leads endpoint migration

What does this MR do and why?

This MR is the second part of the hand raise leads endpoint migration (see https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/14265 for the CustomersDot side).

Problem: GitLab.com currently routes all hand raise lead creation to the legacy trials_controller.rb endpoint on CustomersDot. We need to gradually migrate to the new dedicated leads/gitlab_com/hand_raises endpoint without disrupting existing users.

Solution: By implementing a feature flag with per-user actor support, we can:

• Sticky Rollout - Each user consistently gets the same endpoint across requests
• Gradual Migration - Roll out to 5% → 25% → 50% → 100% of users without endpoint switching
• Risk Mitigation - Test the new endpoint with a subset of users before full rollout
• Clean Cutover - Once stable, remove the legacy code path

This MR enables the gradual migration strategy outlined in epic &20083 and works in conjunction with the CustomersDot changes to support the new endpoint.

References

Screenshots or screen recordings

There are no UI changes

How to set up and validate locally

1. Open the Rails console.
2. Enable the feature flag:
   Feature.enable(:new_hand_raise_lead_endpoint)
3. Go to the group billing page:
   groups/<group_id>/-/billings?source=overview-free-tier-highlight
4. Click Talk to an expert.
5. Fill out the form.
6. Open Inspector → Network tab.
7. Submit the form.
   • You should see a request to the new endpoint:
     /leads/gitlab_com/hand_raises
8. Disable the feature flag and repeat the test to confirm the old behavior.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #582231