fix: a caller cannot assign a profile past their own

[blaipr]

isAdminApp and isAdminAcc are gated on the caller already holding them, in the web
form and in the API's user endpoints alike. The profile a user is pointed at was not
gated at all, at either door — and a profile is where the other thirty permissions live.
Assigning one hands the user everything on it, so "may manage users" was "may hold any
permission in the installation" in two steps: create or edit a user, point them at the
administrator profile, sign in as them.

The codebase already answers this question for the other door. ProfileData::constrainedTo()
strips a written profile down to what the writer holds, and the API's ProfileBase
applies it — because otherwise "may manage profiles" was "may become an administrator".
The same escalation was still open next to it, by referencing a profile instead of
writing one.

grantsBeyond() is that question asked of a referenced profile, in terms of the existing
one, so a permission added later is covered without either being revisited.

Placed in UserProfileService and called from the web's UserSaveBase and the API's
UserBase, rather than in UserService::create() — that is also the path the installer
and LDAP auto-provisioning take, where there is no signed-in caller to constrain against.

Two things the tests settled:

A profile that does not exist is let through rather than refused. The integration suite
caught the first version changing what a bad id reports — "Profile not found" instead of
the error the foreign key produces. A profile that is not there grants nothing, so there
is nothing for this guard to say about it.

An application administrator's profile is not even read, which is what the never() in
that test asserts. Checked by making the comparison always false: the refusal test fails
and the two that pin what must still work do not.