Scope security policy project suggestions to the caller's organization

What does this MR do?

SecurityPolicyProjectsFinder#global_projects searched every project on the instance when suggesting a policy project (the picker used to assign a security policy project), and its exact-path-match branch bypassed the visibility/access filter entirely — any project on the instance was returned for an exact path match, regardless of archived state, deletion state, or the caller's access. On self-managed, this "global" search is unconditionally enabled (search_globally = !gitlab_com_subscription?) with no organization scope.

This scopes base_relation to the container's organization, and routes the exact-match branch through base_relation too so it picks up both the visibility filter and the new organization scope.

Two separate things fixed here:

1. A pre-existing visibility bug independent of Cells — the exact-match branch never applied public_or_visible_to_user.
2. The organization-scoping gap this audit is tracking — self-managed "global" search wasn't bounded to the caller's own organization.

Production impact today: the org-scoping half has none (GitLab.com is single-organization). The visibility fix (1) does have a behavioral effect today on self-managed/Dedicated: an exact full-path match will no longer surface a project the caller can't see.

References

Relates to https://gitlab.com/gitlab-com/gl-infra/tenant-scale/organizations/organizations-feature-parity/-/work_items/102 (additional finding beyond the original audit)

How to test

bundle exec rspec ee/spec/finders/security/security_policy_projects_finder_spec.rb