Unmask valid project path in rules:exists errors

What does this MR do and why?

In the case that we have already verified that a project path is valid, masking it in the output of an error message doesn't carry a high risk of leaking information that the user doesn't already have access to. As masking is generally only done on a best-effort basis and even that is only documented to apply to CI job logs rather than error messages, we are not masking the output in these very specific scenarios to make debugging a bit easier.

See prior discussion in !149326 (comment 1984472678)

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before	After

How to set up and validate locally

1. Create two projects proj1 and proj2 with private visibility
2. Add test.txt in proj2
3. Create masked, unprotected CI variable MASKED_PROJECT_PATH in proj1, with the full path to proj2 as content
4. Add .gitlab-ci.yml in proj1:

   # Comment to edit later
   force-job:
     script: exit 0
   
   job:
     script: exit 0
     rules:
       - exists:
           paths: [test.txt]
           project: $MASKED_PROJECT_PATH
           ref: main

5. Add a user as Maintainer to proj1, but not to proj2
6. As that user, go to Pipeline Editor in proj1, edit the comment and commit to trigger a pipeline
   • Observe the error message – the project path contained in $MASKED_PROJECT_PATH is shown with these changes, but masked without them
7. Add the user to proj2 with Developer or above
8. As that user, go to Pipeline Editor in proj1, edit ref: main to any non-existing ref and commit to trigger a pipeline
   • Observe the error message – the project path contained in $MASKED_PROJECT_PATH is shown with these changes, but masked without them