MID-9639 Fix authorization for reference searches

[kay1313]

Summary

Fixes MID-9639 by applying model-level authorization preprocessing to object-owned reference searches.

The All accesses panel loads role memberships through model reference-search APIs over roleMembershipRef. Before this change, ModelController.preProcessReferenceQuerySecurity(...) was effectively a TODO and returned the query unchanged. As a result, a user with denied read access to UserType/roleMembershipRef could still see role membership references in the All accesses panel.

This change applies authorization preprocessing for object-owned reference searches:

• validates the reference-search query shape using shared ObjectQueryUtil.extractOwnedByFilterForReferenceSearch(...)
• applies normal owner-object search authorization through securityEnforcer.preProcessObjectFilter(...)
• checks whether the current principal can read the owned reference item path
• converts the query to NoneFilter if the owner search or reference item read is denied
• preserves previous behavior for non-object/container-owned reference searches; authorization preprocessing for those searches is out of scope for this fix because it requires resolving the containing object type and translating container filters to object-level filters. The All accesses panel fixed by this ticket uses object-owned roleMembershipRef reference searches.

The same preprocessing is used for:

• searchReferences(...)
• countReferences(...)
• searchReferencesIterative(...)

Behavior

If the current principal is denied read access to UserType/roleMembershipRef, model reference search now returns:

• empty result list for searchReferences(...)
• zero for countReferences(...)
• no callbacks for searchReferencesIterative(...)

Malformed reference-search query shapes are still rejected consistently with repository validation. NoneFilter remains a valid empty query.

Tests

Added regression coverage in TestSecurityBasic:

• test321AutzDenyReadRoleMembershipRefReferenceSearch
• test322AutzDenyReadRoleMembershipRefReferenceCount
• test323AutzDenyReadRoleMembershipRefReferenceIterative

These tests fail on master because the denied user still sees/counts/iterates two roleMembershipRef values, and should pass with this patch.

Manual verification

Reproduced on master through GUI:

1. Import a user with assignments and a role denying read access to assignment and roleMembershipRef.
2. Log in as that user.
3. Open User profile → All accesses.
4. Role membership references are still visible despite the deny authorization.

With this patch, the All accesses panel should not show those role membership references.