Migrate project secrets pipeline JWT to use CEL authentication

Problem Statement

Currently, project secrets use two different JWT authentication mechanisms:

• User JWT: Uses CEL-based authentication (newer approach)
• Pipeline JWT: Uses native JWT authentication (older approach)

Group secrets, implemented more recently, use CEL-based authentication for both user and pipeline contexts.

This inconsistency creates:

1. Maintenance burden: Two different authentication code paths to maintain
2. Migration complexity: Future changes to authentication logic need to handle both mechanisms
3. Inconsistency: Projects and groups behave differently
4. Technical debt: The native JWT approach is the older pattern we're moving away from

Proposal

Migrate project secrets pipeline JWT to use CEL-based authentication, matching the group secrets implementation.

Benefits

1. Consistency: Both project and group secrets use the same authentication mechanism
2. Simplified maintenance: Only one authentication pattern to maintain
3. Easier migration: Migrating now (before Beta) is less risky than after customer adoption
4. Future-proof: Aligns with the direction established by group secrets implementation
5. Simplified architecture: As noted by @cipherboy-gitlab, we could potentially consolidate to a single auth mount with two roles instead of separate pipeline_jwt and user_jwt mounts

Why Now (Before Beta)?

• Lower risk: Fewer users/projects to migrate
• Easier reprovisioning: Can reprovision projects without customer impact
• Clean slate: Start Beta with consistent architecture
• Avoid future breaking changes: Migrating after Beta would require customer coordination

Technical Approach

Based on discussion with @cipherboy-gitlab:

1. Consolidate auth mounts: Since auth is now within the namespace, we could use a single auth mount with two roles (pipeline and user) instead of separate pipeline_jwt and user_jwt mounts
2. Migrate pipeline role to CEL: Convert the pipeline JWT role to use CEL-based authentication
3. Update provisioning service: Modify project secrets manager provisioning to create CEL-based pipeline roles
4. Migration path: Reprovision existing project secrets managers to use the new authentication

Implementation Considerations

• This should be done before Beta to minimize migration impact
• Existing projects would need reprovisioning (acceptable pre-Beta)
• Group secrets already use this pattern, so we have a working reference implementation
• Long-term, common configuration will be addressed by the next-gen design doc

Related

• Discussion in !214892 (merged): !214892 (comment 2935505109)
• Group secrets implementation (reference): Uses CEL for both user and pipeline auth
• Slack discussion: https://gitlab.slack.com/archives/C09GSEDT50U/p1733436254123829

Acceptance Criteria

• Project secrets pipeline JWT uses CEL-based authentication
• Consistent with group secrets authentication mechanism
• Single auth mount with two roles (if feasible)
• Existing project secrets managers can be reprovisioned
• Documentation updated to reflect the authentication mechanism
• No regression in pipeline secret access functionality