GitLab Administrator not _always_ able to use (deploy to) protected environments

In the docs on protecting manual jobs, we say:

Only those in this list can trigger this manual job, as well as GitLab administrators who are always able to use protected environments.

This is not entirely true. It is not always possible for a GitLab administrator to deploy to a protected environment.

• A GitLab administrator can deploy to a protected environment in an Internal project where they were not a direct member.
• A GitLab administrator can not deploy to a protected environment in a Private project where they were not a direct member.
• A GitLab administrator can deploy to a protected environment in a Private project where they were a direct member.

If a GitLab administrator attempts to run a manual job that deploys to a protected environment in a Private project, they'll see errors like:

Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /builds/group/private/.git/
remote: You are not allowed to download code from this project.
fatal: unable to access 'https://gitlab.example.com/group/private.git/': The requested URL returned error: 403
Cleaning up project directory and file based variables

I believe this is working as documented in the job permissions table where we see that Administrator can only clone source and LFS from private projects if they are a member of the project.

Though this does appear to be working as documented, the Executing Pipeline for non members of project fails with 403, even if user is an admin issue captures the request for this behavior to be changed.

This is a draft issue based on my conversation with a customer in a ticket that is available to GitLab team members with access to Zendesk.