Add troubleshooting for protected jobs as admin

What does this MR do?

Adds a troubleshooting section regarding the problem described in Disable/remove the run pipeline option for non-... (#23130)

We've had a customer run into this issue and verified/documented the current behavior in GitLab Administrator not _always_ able to use (... (#349568)

---

I first considered adding a caveat/warning to the sentence in https://docs.gitlab.com/ee/ci/jobs/job_control.html#protect-manual-jobs, something like this:

Only those in this list can trigger this manual job, as well as GitLab administrators who are always able to use protected environments. Note that in private projects these jobs might fail due to administrators not being allowed to clone the project's source unless they are a direct member of them.

I decided for a troubleshooting section instead for two reasons:

1. I found it hard to describe the problem in a concise enough way to not be too long for adding it directly to that section.
2. While most people will probably encounter this in the context of the "protect manual jobs" section, the sentence is technically correct. The administrator absolutely can trigger the manual job. It will fail afterwards, however a job with GIT_STRATEGY: none might even work as it would not run into the problem of not being allowed to clone the source.

---

@marcel.amirault Happy for any advice if you'd disagree with where and how to add this information.

Related issues

Both issues are mentioned in context above:

• #23130
• Solves #349568

Author's checklist

• Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• Ensure that the product tier badge is added to topic's h1.
• Request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Review checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
• Ensure a release milestone is set.