Read the Secrets Manager beta cohort from the entitlement

What does this MR do and why?

This MR follows the backend fix for the self-managed Secrets Manager beta cohort (merged: !254012 (merged)). It makes the frontend read the beta signal from the entitlement instead of from a SaaS-only enrollment query, so self-managed beta instances get the same UI treatment as GitLab.com beta groups.

Changes:

• secrets_app.vue: isBetaUser now returns Boolean(this.entitlement?.betaWindowEligible). Removes the separate getSecretsManagerEnrollment Apollo query (previously skipped when isSaas was false), its enrollment data property, and the isSaas inject that only it used.
• get_secrets_manager_entitlement.graphql: adds betaWindowEligible.
• get_secrets_manager_enrollment.query.graphql: deleted, no remaining consumer.
• Specs updated accordingly: secrets_app_spec.js (beta cases now drive betaWindowEligible on the entitlement response, including false, null, and self-managed), mock_data.js in both ee/spec/frontend/ci/secrets and ee/spec/frontend/pages/projects/shared/permissions/secrets_manager (add betaWindowEligible to the entitlement mock, remove enrollment mocks).

Why GitLab.com behavior is unchanged: every consumer of isBetaUser (the banner, isBetaReadOnly, the status query skip, the trial empty state, the secret form redirect) is also gated on the TRIAL_ELIGIBLE state, and in that state betaWindowEligible equals the old enrollment.beta. The entitlement field is readable by anyone who could already read the old enrollment query, so there is no new exposure.

Effect on self-managed: a beta instance now sees its secrets table instead of the trial onboarding screen, can create and edit secrets until the beta program ends, and drops to a read-only view once end_secrets_manager_beta_program is enabled. The beta transition banner stays GitLab.com-only: secrets_beta_transition_alert.vue is untouched, and self-managed messaging for the beta end is a separate product decision (!254013 (comment 3800523052)).

References

• Closes https://gitlab.com/gitlab-org/gitlab/-/work_items/627946
• Beta marker on SaaS enrollment: !249180 (merged)
• Beta program end flag: !249902 (merged)
• Rollout issue for the two flags: https://gitlab.com/gitlab-org/gitlab/-/work_items/616379
• Frontend banner follow-up work: https://gitlab.com/gitlab-org/gitlab/-/work_items/623322
• Backend MR (merged): !254012 (merged)

Screenshots or screen recordings

There is no visual change on GitLab.com. Self-managed, secrets_manager_paid_experience enabled, instance enrolled and provisioned during the beta. "After" screenshots to be added by the author before review; see the validation comment for the full matrix.

Page	Before (master)	After (this MR)
Group Secure > Secrets manager		to be added
Project Secure > Secrets manager		to be added

How to set up and validate locally

1. Check out this branch on top of master, which already contains the backend change. Use the same self-managed GDK setup as the backend MR: instance enrolled, a top-level group with a provisioned secrets manager and at least one secret, secrets_manager_paid_experience enabled, CustomersDot returning trial_eligible.
2. Visit the group's Secure > Secrets manager page. Expected: the secrets table with the existing secret and a working "Add secret" flow; no beta banner on self-managed. Before this MR the page showed the trial onboarding screen.
3. Open a project under that group and visit its Secure > Secrets manager page. Expected: the same table. Before this MR the page returned 404.
4. Enable end_secrets_manager_beta_program. Reload. Expected: the secrets stay listed but the page is read-only (no add, edit, or delete controls).
5. Run yarn jest ee/spec/frontend/ci/secrets.

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.