Do not expose organization groups through the SCIM Users groups attribute - #51591

Closes #51590

Organization groups — and the organization's internal backing group — were exposed through the groups attribute of the SCIM Users resource.

AbstractUserModelSchema.getAttributeValue returned model.getGroupsStream() filtered only by canViewGroup, which resolves to GroupPermissionsV2.canView(group) and short-circuits to true for any caller holding view-users or manage-users. There was no group-type check on that path. Since organization membership is itself a membership in the organization's internal group, both that group and any organization groups were returned.

The same boundary is already enforced for the Groups resource (#50310 / #50311) and on the SCIM user write path in UserCoreModelSchema.checkGroupMembershipPermission, which throws "Cannot access organization related group via non Organization API.". This aligns the read path with those.

The predicate used by the write path is extracted into AbstractUserModelSchema.isOrganizationGroup and reused on both sides, so the two cannot drift apart. It matches the existing behaviour exactly (Type.ORGANIZATION and a non-null organization); both the internal group and organization groups carry the organization relationship, set in JpaOrganizationProvider on organization creation and in createGroup respectively.

Added UserTest#testOrganizationGroupsNotExposedOnUser, which puts a user in a realm group, an organization, and an organization group, then asserts that only the realm group is returned by GET /Users/{id}?attributes=groups.

Note for reviewers: UserResourceTypeProvider.getAttributeExpression maps the SCIM groups filter onto UserGroupMembershipEntity.groupId without a type restriction, so a user can still be filtered by a known organization group id. That is a separate surface from serialization and is left out of this change — happy to follow up if you would like it covered here or in its own issue.