What does this PR do?

The membership privacy policy is documented as controlling what a member can see about other members:

Updating this policy allows you to control if team members can see other members information. When enabled, all team members can see ID, name, email, phone number, and MFA status of other members.

But GET /v1/teams/:teamId/memberships and GET /v1/teams/:teamId/memberships/:membershipId applied it to every membership in the response, the requester's own included.

New projects are created with every flag disabled (membershipsUserId => false in Projects/Http/Projects/Create.php) — the ?? true fallback in the endpoints only covers projects that predate the policy. So on a fresh project a standard user listing team memberships gets userId: "" on every row, including their own, and has no way to tell which membership is theirs.

That is not just cosmetic. DELETE /v1/teams/:teamId/memberships/:membershipId explicitly supports self-removal, but finding your own membershipId requires matching on userId — so a member could not leave a team. The same applies to requests authenticated with a user JWT from a function, which is neither privileged nor a key.

This exempts the requester's own membership from the policy, treating it like a privileged read. It reuses the userInternalId === $user->getSequence() check that Memberships/Delete.php and Memberships/Update.php already use to recognise the caller's own membership. Nothing is actually concealed by the old behaviour — GET /v1/account returns every one of these fields about yourself.

Other members' details are unaffected: the policy still governs them exactly as before, and API keys / admin mode are unchanged.

Test Plan

tests/e2e/Services/Teams and tests/e2e/Services/Project.

Three existing tests asserted the old behaviour on a team where the viewer was the only member, so they now cover the distinction between self and other rather than conflating them:

• TeamsCustomClientTest::testGetMembershipPrivacy — invites a second member. Policy assertions target that member; the viewer's own row is asserted visible in all three policy states.
• PoliciesMembershipPrivacyIntegrationTest::testMembershipPrivacyIntegration — step 4 now asserts user2's row is hidden from user1 and user1's own row is not.
• testMembershipUserAccessedAtDefault / testMembershipUserAccessedAtPolicy — createTeamWithMember now creates a signed-in viewer plus one other member, so the userAccessedAt policy is exercised against the other member.

Manual reproduction from the issue:

1. Create a project, add a user under Auth, create a team, add the user to the team.
2. Sign in as that user with a client SDK and call teams.listMemberships(teamId).
3. Before: userId is "" on the user's own membership. After: it is their user ID, while any other member's row still follows the project policy.

composer lint and composer analyze pass on the four changed files.

Related PRs and Issues

• Fixes Standard users are not sent userId when listing memberships #13767

Checklist

• Have you read the Contributing Guidelines on issues?
• If the PR includes a change to an API's metadata (desc, label, params, etc.), does it also include updated API specs and example docs? — no metadata change, response behaviour only