Add permission checks to analytics dashboards scope picker

What does this MR do and why?

Summary

This change adds permission-based restrictions to the analytics dashboard scope picker. Dashboards can now declare required permissions (starting with readProAiAnalytics) in their YAML configuration, and any group or project the user lacks that permission for will be shown as disabled with a "Restricted" badge and a tooltip explaining why it can't be selected. Groups missing the permission are still visible so users can browse and select accessible subgroups or projects beneath them, but the groups themselves cannot be chosen. Previously saved selections that no longer meet the permission requirements are also silently dropped on load. The DAP Impact and Duo & SDLC Trends dashboards are the first to use this new restriction.

References

gitlab-org/gitlab#630768

Screenshots or screen recordings

Before	After

How to set up and validate locally

Setup

1. Use a GDK with an EE license of Premium or higher (the permission needs the ai_analytics feature).
2. Enable the feature flags in the Rails console:

   Feature.enable(:explore_analytics_dashboards)
   Feature.enable(:dap_impact_v1)

   Test on DAP Impact. ClickHouse is only needed for panel data or for the Duo and SDLC trends dashboard, not for the picker itself. See doc/development/database/clickhouse/clickhouse_within_gitlab.md if you want it.
3. Create a user in Admin > Users > New user with username scope-tester and a password.
4. Pick two top-level groups from GDK seed data that each have at least two projects. Then run this in the Rails console:

   user = User.find_by_username('scope-tester')
   Group.find_by_full_path('<group-a>').add_reporter(user)               # fully accessible
   Group.find_by_full_path('<group-b>').add_guest(user)                  # restricted group
   Project.find_by_full_path('<group-b>/<project-1>').add_reporter(user) # accessible project inside it

   readProAiAnalytics needs Reporter or higher (inherited counts). Guest and Planner do not have it.

Validate

Sign in as scope-tester, open /explore/analytics_dashboards/dap_impact, and open the scope picker.

1. <group-a> is selectable, with no badge.
2. <group-b> is disabled with a Restricted badge. Hover the badge to see: "You have restricted access to this group, so you can't select it. You can select projects and subgroups listed below it instead."
3. Expand <group-b>. <project-1> is selectable. Another project in it shows Restricted with the tooltip "You have restricted access to this project, so you can't select it."
4. Search for <group-b> or one of its restricted projects. Results show the same Restricted state.
5. Scope URL param:
   • ?scope=<group-b> leaves the picker empty.
   • ?scope=<group-a>,<group-b> keeps only <group-a>.
6. Default scope:
   • Visit the <group-b> group page a few times, then open the dashboard with no scope param. Nothing is preselected.
   • Repeat with <group-a>. It is preselected.
7. Optional regression: sign in as a user with Reporter or higher on both groups. Nothing is restricted.

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 #630768