feat: open the last locked fields for editing, keeping their history intact

Four fields were still frozen because changing them would have bypassed the
record that makes the change traceable, and a user's login data could not be
corrected at all. Locking a field is the wrong trade: a wrong value stays in
the system forever. The fix is to let the edit write the same history entry the
dedicated endpoint writes.

- A colony's apiary is editable through PATCH and writes the same
  ColonyApiaryHistory entry POST /colonies/:id/move writes, so the location
  history never skips a stand the colony was recorded on.
- A honey batch's storage container is editable through PATCH and writes the
  same HoneyBatchRelocation entry POST /honey-batches/:id/relocate writes.
- A stock item's quantity is editable and books the difference as an ADJUSTMENT
  movement, so the stored level stays the sum of its movements.
- A role's key is editable (system roles were already rejected outright by
  RolesService.update, which keeps the seed's ADMIN lookup intact).
- A user's e-mail - the login identity - is editable. A typo there previously
  locked the account out for good.
- New POST /users/:id/reset-password lets an administrator set someone else's
  password: there is no self-service reset flow, so a forgotten password was
  the one thing no edit could repair. It revokes every refresh token and clears
  the permission cache exactly as a self-service change does, refuses to act on
  your own account (that goes through /profile/password, which proves ownership
  by asking for the current one), and never writes the password to the log.

Frontend:
- Users had no edit UI at all, although PATCH /users/:id existed. New
  EditUserDialog covers name, e-mail, role and an optional new password.
- Colony, honey batch and stock item forms gained the newly editable fields,
  each with a note saying the correction is recorded as a move, a relocation
  or a stock adjustment.
- The role dialog gained the key field.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

ApiCore-Backend/src/users/users.service.ts

@@ -11,6 +11,7 @@ import { PermissionResolverService } from '../auth/permissions/permission-resolv
 import { Prisma } from '../../generated/prisma';
 import { CreateUserDto } from './dto/create-user.dto';
 import { UpdateUserDto } from './dto/update-user.dto';
+import { ResetUserPasswordDto } from './dto/reset-user-password.dto';
 
 const BCRYPT_SALT_ROUNDS = 12;
 
@@ -194,6 +195,7 @@ export class UsersService {
       where: { id },
       data: {
         name: dto.name,
+        email: dto.email,
         roleId: dto.roleId,
       },
       ...USER_WITH_ROLE,
@@ -240,6 +242,49 @@ export class UsersService {
    * a stolen access token alone (no password) would be enough to strip the
    * victim's own MFA protection via this admin route.
    */
+  /**
+   * Sets a new password for another user. Mirrors ProfileService.changePassword
+   * in what it invalidates: every refresh token is revoked and the permission
+   * cache is cleared, so sessions opened with the old password stop working at
+   * once rather than living on until their access token expires.
+   *
+   * Your own password goes through /profile/password, which requires the
+   * current one - otherwise anyone holding users:update could silently take
+   * over their own account's credentials without proving they own it.
+   */
+  async resetPassword(
+    id: string,
+    dto: ResetUserPasswordDto,
+    actingUserId?: string,
+  ): Promise<UserSummary> {
+    if (actingUserId && id === actingUserId) {
+      throw new ForbiddenException(
+        'Use /profile/password to change your own password',
+      );
+    }
+    await this.findById(id);
+    const passwordHash = await bcrypt.hash(dto.password, BCRYPT_SALT_ROUNDS);
+    const user = await this.prisma.user.update({
+      where: { id },
+      data: { passwordHash, passwordChangedAt: new Date() },
+      ...USER_WITH_ROLE,
+    });
+    await this.prisma.refreshToken.updateMany({
+      where: { userId: id, revokedAt: null },
+      data: { revokedAt: new Date() },
+    });
+    this.permissionResolver.invalidateUser(id);
+    // The new password never reaches the audit log - only the fact that it
+    // was replaced, and by whom.
+    await this.auditLog.record({
+      entityType: 'User',
+      entityId: id,
+      action: 'UPDATE',
+      userId: actingUserId,
+    });
+    return this.toSummary(user);
+  }
+
   async resetMfa(id: string, actingUserId?: string): Promise<UserSummary> {
     if (actingUserId && id === actingUserId) {
       throw new ForbiddenException(