[2.x] fix: Avoid loading target user's groups in editCredentials check

[imorland]

Fixes #4724.

Problem

UserPolicy::editCredentials() evaluated $user->isAdmin() — which reads $user->groups — before checking whether the actor can edit credentials at all:

if ($user->isAdmin() && ! $actor->isAdmin()) {
    return $this->deny();
}
if ($actor->hasPermission('user.editCredentials')) {
    return $this->allow();
}
return null;

UserResource's email-field visibility calls editCredentials for every serialized user. On render paths that serialize many users, $user->isAdmin() lazy-loads each one's groups — one group_user query per user. #4696 fixed this for post authors on the JSON:API posts endpoint by eager-loading user.groups, but it does not cover other serialized users — notably the likers included by default via flarum-likes' likes relationship, whose groups are not eager-loaded for post-stream posts.

Fix

Check the actor's user.editCredentials permission first and return no opinion when they lack it. Guests and normal users — the vast majority of serialized actors — never reach $user->isAdmin(), so the target user's groups are never loaded. $user->isAdmin() is only consulted when the actor can actually edit credentials, where it is needed to stop a non-admin from editing an admin's credentials.

This eliminates the work for the common case rather than batching it, and the visibility outcome is unchanged in every case:

actor has editCredentials	target is admin	actor is admin	before	after
no	–	–	deny/null → not allowed	null → not allowed
yes	no	–	allow	allow
yes	yes	no	deny	deny
yes	yes	yes	allow	allow

Tests

• New regression test in flarum-likes (ListPostsTest::likers_groups_are_not_loaded_individually): asserts likers' groups are batch-loaded, not one query per liker. Fails without this change (loads them individually), passes with it.
• The existing user API + policy suite (114 tests) remains green, covering the credential-protection behaviour the table above preserves.