## Problem Non-CI/CD secret access (#594090) adds a new `api_jwt` OpenBao mount and `all_api_access` CEL role. The provision service creates these for **new** SM enrollments. Projects and groups already enrolled in Secrets Manager will not have the new mount and role, so the access-token endpoint will not work for them until they are backfilled. ## Proposal Backfill the `api_jwt` mount and `all_api_access` CEL role into every already-enrolled SM namespace, reusing the same provisioning code path #594090 adds for new enrollments. - Iterate existing project and group secrets managers. - For each, provision the `api_jwt` mount + role if missing (idempotent). - Anchor on the existing maintenance-task / cron pattern so a crash leaves the work retryable, consistent with how provisioning and deprovisioning already recover. ## Scope - In scope: the backfill itself, idempotency, retry/recovery, and its spec. - Out of scope: the endpoint, the JWT class, and new-enrollment provisioning (all in #594090). ## Notes - Additive only. Existing `pipeline_jwt` and `user_jwt` mounts are untouched. - Should run safely on GitLab.com scale and on self-managed. ## Related - #594090 (endpoint + new-enrollment provisioning, this issue's parent)