Say what edit_clients and edit_users reach, and document the new refusals

Setting a password and removing a second factor are how an
administrator lets a locked-out person back in, so a token holding
edit_clients or edit_users can sign in as the accounts it may edit. That
stays what those abilities mean; it is now said where it is chosen. The
token form warns when either is ticked, and the API guide says it beside
the abilities, with the three refusals on your own account under "Staff
accounts". The OpenAPI document carries the new 403s, and CHANGELOG.md
an Unreleased entry.

GHSA-j5cp-r8pr-m5cr

app/Modules/Identity/Http/Controllers/Api/UsersController.php

@@ -160,6 +160,11 @@ class UsersController extends Controller
      *
      * Refused with a 422 if the change would leave the installation with
      * no active administrator, or if you would be deactivating yourself.
+     *
+     * Your own email address and password cannot be changed here: that is
+     * a `403`. Change them from your profile in the web interface, which
+     * asks for your current password. Setting somebody else's password
+     * signs them out of the API: every token they hold is revoked.
      */
     public function update(Request $request, User $user): StaffUserResource
     {
@@ -278,6 +283,9 @@ class UsersController extends Controller
      * The account holder is emailed that this happened, and the action is
      * recorded in the activity log against the caller. Answers 204 whether
      * or not a second factor was actually in force.
+     *
+     * Not for your own account, which is a `403`: remove your own second
+     * factor from your profile in the web interface.
      */
     public function destroyTwoFactor(Request $request, User $user, TwoFactorAdministration $twoFactor): JsonResponse
     {