Composite identity should work on projects where project members cannot be added

There is a setting in GitLab that disables new project members from being added: https://docs.gitlab.com/user/group/access_and_permissions/#prevent-members-from-being-added-to-projects-in-a-group

Right now, this means that features which use composite identity will not work in projects that enable this setting

See bug report Slack thread

I tried several UI-based use cases including Issue-MR and the Jenkins-CI buttons and in each case, the Agent session gets opened, but never does anything at all, no logs, no nothing and eventually fails with no details.

This fails because composite identity requires that the service account being used is added to the project.

Proposed Solution

Original reasoning in #577607 (comment 3081699815):

Adding composite identity Service Accounts should ignore the setting.

This will allow flows and external agents to be added, even if the feature is turned on.

Reasoning

Original explanation in #577607 (comment 3081699815)

The set of human users who can act on the project doesn't change. The composite identity SA is just a constrained proxy for an already-authorized human, not a new actor. This is fundamentally different from a project_bot / security_policy_bot comparison, since those bots act autonomously whereas composite identity SAs literally cannot.

There's also precedent for this, SAs were already excluded from LDAP group sync enforcement for the same practical reasons. The compliance concern there was identical (LDAP sync is the SSoT, don't let anything bypass it), and the resolution was the same: exempt SAs because requiring admins to disable the setting, add the SA, and re-enable it doesn't scale. We're hitting the exact same pattern here with "prevent member invitations".