Remove Secrets Manager enrollment feature flags

What does this MR do and why?

Related: MR 2 of 6 removing Secrets Manager feature flags for GA. Targets master now that !259222 (merged) is merged. Related to #599755 (closed).

All MRs in this series

1. secrets_manager, group_secrets_manager: !259222 (merged) (merged)
2. Enrollment flags (secrets_manager_namespace_enrollment, secrets_manager_instance_enrollment): !260090 (merged) (this MR)
3. secrets_manager_async_audit_logs: !260091 (merged)
4. Billing event flags (secrets_manager_emit_secret_read_events, secrets_manager_emit_secret_stored_events): !260092 (merged)
5. secrets_manager_denial_telemetry: !260094 (merged)
6. secrets_manager_paid_experience: !260110 (merged)

secrets_manager_api_access stays in beta and default disabled for GA, so it is not part of this series.

Problem

• secrets_manager_namespace_enrollment (off by default) and secrets_manager_instance_enrollment (on by default) still gate enrollment checks, even though the underlying logic is final.
• The rollout issue for the namespace flag is closed, but its production rollout checklist still has unchecked steps. This needs a check before we remove the flag.

Solution

• Make NamespaceEnrollment.enrollment_allowed? depend only on being a licensed SaaS root group, and InstanceEnrollment.enrollment_allowed? depend only on not being GitLab.com plus a license. Both drop their flag check.
• Keep enrollment_allowed? as a thin wrapper, so callers (GroupPolicy, GlobalPolicy, EE::Group, NamespaceEnrollmentService, EnrollmentHelper) do not need to change.
• Remove the enable_feature_flags step from the GDK seed rake task, since there are no flags left to enable, and its matching spec block.
• Remove both flags from QA_FEATURE_FLAGS in the cng-secrets-manager CI job.
• Docs: add a "Feature flags secrets_manager and group_secrets_manager removed in GitLab 19.5" history entry to doc/ci/secrets/secrets_manager/_index.md, since the step 1 MR (!259222 (merged)) shipped without one. Also remove the remaining flag mentions for those two flags and the enrollment flags from the developer docs (_index.md, enrollment.md).
• Specs: remove the flag stubs and the flag-disabled contexts. The enroll_with_add_on_intent "enrollment is forbidden" case now uses an unlicensed group instead of the flag, so the error-propagation path stays covered. The subgroup, no-license, and self-managed contexts already cover the other "not allowed" paths.

Impact

• secrets_manager_instance_enrollment is on by default, so no change for default installs.
• secrets_manager_namespace_enrollment is off by default. After this MR, on GitLab.com, licensed top-level group Owners can enroll or unenroll, and the trial/add-on flows that depend on enrollment_allowed? become reachable without the flag.
• No database changes.
• Changelog: commit trailer Changelog: changed and EE: true.

Before merge

• Confirm with chatops that secrets_manager_namespace_enrollment is fully enabled in production.

After merge

• Delete the flags from all environments: /chatops gitlab run feature delete secrets_manager_namespace_enrollment secrets_manager_instance_enrollment --dev --pre --staging --staging-ref --production
• Retarget is automatic: when the previous MR merges and its branch is deleted, GitLab retargets this MR to master.

References

• Related to #599755 (closed) (rollout issue)

Screenshots or screen recordings

Not applicable. No UI change.

How to set up and validate locally

1. Run the changed specs:

   bundle exec rspec ee/spec/models/secrets_management/namespace_enrollment_spec.rb ee/spec/models/secrets_management/instance_enrollment_spec.rb ee/spec/services/secrets_management/namespace_enrollment_service_spec.rb ee/spec/requests/api/graphql/mutations/secrets_management/enrollment ee/spec/tasks/gitlab/secrets_management/seed_rake_spec.rb

2. On a GDK with GITLAB_SIMULATE_SAAS=1 and no feature flags set, open the Secure settings of a licensed top-level group as an Owner and check that the enrollment toggle shows.

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.