Expose can_enable_add_on and can_provision to the secrets manager UI

What does this MR do and why?

The Secrets Manager frontend decides which action buttons to show (Start trial, Enable with GitLab Credits, New secret) based on role and whether the instance is SaaS. It does not ask the backend. This causes bugs:

• A Reporter sees "New secret" on an unprovisioned project, even though only an Owner can provision.
• A self-managed group Owner sees "Start trial" and "Enable with GitLab Credits", even though those are admin-only on self-managed.

The backend already denies these actions correctly. The frontend just has no way to check before rendering.

This MR adds three booleans to the data the backend sends to the Secrets Manager UI, in the same style as the existing can_start_trial:

• can_enable_add_on: wraps the enable_secrets_manager_add_on ability. False for personal namespaces, since there is no trial or add-on there.
• can_provision: wraps provision_secrets_manager on both group and project pages. Gates the provision CTA on an unprovisioned scope.
• can_create_secret: wraps create_secret (group) / create_project_secrets (project). Gates the "New secret" button once the scope is provisioned. This is Reporter and above, so it must not be confused with can_provision, which is Owner-only.

Permission change

Projects only had the coarse admin_project_secrets_manager for provisioning, while groups already split it into provision_secrets_manager, deprovision_secrets_manager, update_secrets_permission and delete_secrets_permission. Following authorization review, this MR brings the project side in line for provisioning:

• provision_secrets_manager is added to the Owner role for projects in config/authz/roles/owner.yml.
• ProjectPolicy prevents it in the same three places it prevents admin_project_secrets_manager (Secrets Manager unavailable, entitlement denies access, entitlement denies writes).
• ProjectSecretsManagerInitialize authorizes on provision_secrets_manager instead of admin_project_secrets_manager. The granular-token check already used it.
• can_provision reads provision_secrets_manager, so no Gitlab/Authz/PermissionCheck rubocop disable is needed.

Who can provision a project does not change: Owner and admin only, in write entitlement states. admin_project_secrets_manager stays for the deprovision and permissions mutations and for canManageSecretsManager on the project settings page. Moving those off the coarse ability is a follow-up.

Frontend adoption (making the UI read these values) is out of scope and lands in separate frontend MRs, starting with !256976 (merged). The frontend should fail closed when a value is missing.

Test coverage

The abilities behind these booleans already had role coverage, and provisioning had entitlement coverage, but nothing asserted how the dimensions combine. This MR adds a "Secrets Manager UI abilities matrix" describe to each policy spec, driven by a new shared examples file (ee/spec/support/shared_examples/policies/secrets_manager_ui_abilities_shared_examples.rb, which also holds a table of expected outcomes).

• GroupPolicy: start_secrets_manager_trial, enable_secrets_manager_add_on, provision_secrets_manager (top-level group and subgroup), create_secret.
• ProjectPolicy: provision_secrets_manager (group project and personal-namespace project), create_project_secrets. The existing role-by-role Secrets Manager block also gains a provision_secrets_manager describe next to admin_project_secrets_manager.
• GlobalPolicy: instance-level start_secrets_manager_trial and enable_secrets_manager_add_on.

Dimensions: 10 roles (anonymous, non-member, guest, planner, reporter, developer, maintainer, owner, auditor, admin) x 2 realms (SaaS, self-managed) x 12 entitlement states (ineligible, all five blocked reasons, trial_eligible, trial_eligible with the beta window open, trial_eligible with the beta window ended, trial, paid, offline_paid). Negative cases on top: admin without admin mode, license off, paid-experience flag off, namespace-enrollment flag off, Secrets Manager availability off.

Outcomes pinned:

• Group trial and add-on: SaaS Owner and admin in every state. Never on self-managed. Never on subgroups. Still allowed when availability is off, so an Owner who opted out can get back in.
• Instance trial and add-on: self-managed admin only. Never on SaaS.
• Provision (group and project): Owner and admin, only in write states (trial, paid, offline_paid, trial_eligible with an open beta window).
• Create secret (group and project): Reporter and above, only in write states. No SaaS/self-managed branch.

What's not in this MR

• #630328: the ability layer does not know that ProjectSecretsManagers::InitializeService refuses personal-namespace projects, so can_provision can be true where provisioning will fail. Pre-existing, also affects canManageSecretsManager.
• Moving the deprovision and permissions mutations, and canManageSecretsManager, off admin_project_secrets_manager onto the granular abilities.

Follow-up work planned for 19.6:

• Replace the admin_group proxy check in namespace_enrollment_data with a real ability.
• Expose these abilities through GraphQL userPermissions.
• Distinguish an OpenBao outage from a real access denial.

References

• Related to #601817 (closed)
• Related to https://gitlab.com/gitlab-org/gitlab/-/work_items/629638
• Related to #630328

How to set up and validate locally

1. Run the policy matrix specs:

   bin/rspec ee/spec/policies/ee/group_policy_spec.rb ee/spec/policies/project_policy_spec.rb ee/spec/policies/global_policy_spec.rb -e 'Secrets Manager'

2. Run the helper spec and the project provisioning mutation specs:

   bin/rspec ee/spec/helpers/secrets_helper_spec.rb ee/spec/requests/api/graphql/secrets_management/project_secrets_managers/initialize_spec.rb

3. Run the role definition and permission checks:

   bin/rspec spec/lib/authz/role_definitions_spec.rb
   bundle exec rake gitlab:permissions:validate

4. Optional manual check: on GDK, sign in as a group Owner, open a group or project Secrets page, and inspect #js-group-secrets-manager or #js-project-secrets-manager for the data-can-enable-add-on, data-can-provision and data-can-create-secret attributes.

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.