feat: version 4.6.0 -- Cambio de correo con aprobacion

El usuario solicita el cambio desde Mi cuenta (correo nuevo + clave actual). Lo
aprueba un admin/superadmin (colaboradores), solo un superadmin (admins) o el propio
superadmin mediante enlace a su correo actual. Tras aprobar se envia confirmacion al
correo nuevo y aviso al actual; al confirmar se aplica el cambio y se cierran todas
las sesiones. Todo el proceso queda en auditoria. Migracion 035.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

AGENTS.md

@@ -107,6 +107,7 @@ Adaptación web (no es una app empaquetada, corre en pestaña de navegador):
 ## Seguridad (proyecto con auth/usuarios)
 
 - Permisos validados SIEMPRE en el backend, nunca solo en el frontend.
+- Cambio de correo con aprobación (v4.6.0): reautenticación, aprobador según rol y confirmación en el correo nuevo; sesiones revocadas solo al aplicar (migración 035).
 - Autorregistro con doble candado (decisión posterior al MVP inicial, ver `SPEC.md`): el usuario
   se crea a sí mismo pero queda `pending_verification` → confirma su correo (token de un solo uso,
   24h) → `pending_approval` → un `admin`/`superadmin` aprueba (elige rol/departamento) o rechaza
@@ -132,6 +133,7 @@ Adaptación web (no es una app empaquetada, corre en pestaña de navegador):
 - Sin SMTP configurado, el sistema degrada a modo dev: los correos de verificación/recuperación se
   loguean en la consola del backend en vez de enviarse (nunca rompe el flujo).
 
+
 ## Regla de UX para pantallas
 
 - No mezclar listado y formulario de creación en la vista inicial de un módulo.