feat: autorregistro con verificacion de correo + aprobacion, superadmin y SMTP

- POST /api/auth/register: primer usuario del sistema -> superadmin con sesion
  directa (bootstrap, sin correo ni aprobacion); los siguientes quedan
  pending_verification y reciben un correo con enlace de un solo uso (24h).
- GET /api/auth/verify-email: pasa a pending_approval y notifica in-app a los
  admin/superadmin activos.
- admin/superadmin aprueban (POST /api/users/:id/approve, eligen rol y
  departamento) o rechazan (POST /api/users/:id/reject, borra y audita el
  email) desde Organizacion -> Usuarios (nuevo badge de estado + acciones).
- login() da mensaje especifico segun el status de la cuenta en vez del
  generico "credenciales invalidas".
- Recuperacion de clave (forgot/reset-password): respuesta siempre generica,
  token de 1 hora de un solo uso.
- Nuevo modulo settings: SMTP configurable SOLO por superadmin desde
  Configuracion -> Correo (SMTP); clave cifrada AES-256-GCM (ENCRYPTION_KEY)
  en la tabla system_settings, nunca expuesta por la API. sendMail() degrada
  a modo dev (loguea en vez de enviar) si no hay SMTP configurado, y nunca
  deja que un fallo de envio tumbe al que lo llama.
- Migracion 002_registration_and_smtp.sql: rol superadmin, columnas de ciclo
  de vida en users (status, tokens), tabla system_settings, y promueve al
  usuario mas antiguo del sistema a superadmin.
- Fix: React.StrictMode disparaba el efecto de VerifyEmailPage dos veces; la
  segunda llamada (token ya consumido) mostraba "enlace invalido" pese a que
  la verificacion ya habia funcionado. Se agrega una guarda por token.
- Fix (deuda tecnica v1.0.0): se reordena el montaje de rutas en app.js —
  subtasksRoutes (mount generico en /api) va al final, para no interceptar
  con su requireAuth interno una request sin token dirigida a un router mas
  especifico registrado despues.
- Documentacion actualizada: AGENTS.md, SPEC.md, API.md, BASE_DE_DATOS.md,
  CONFIGURACION.md, ESTADO.md, CHANGELOG.md. Version 1.1.0.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

SPEC.md

@@ -15,7 +15,8 @@ tiene cada cosa — sin que cargar la información sea tedioso para quien lo usa
 
 | Rol | Alcance |
 |---|---|
-| Administrador | Todo, incluida gestión de usuarios/roles/catálogos |
+| Super Administrador | Todo lo de Administrador + configura el SMTP del sistema. Es el usuario más antiguo (bootstrap automático al registrarse el primero) |
+| Administrador | Todo, incluida gestión de usuarios/roles/catálogos y aprobar/rechazar registros |
 | Jefe de TI | Ve y gestiona todos los proyectos/actividades, aprueba; no administra usuarios |
 | Coordinador / Líder de proyecto | Crea/edita los proyectos donde es responsable o miembro, gestiona sus actividades |
 | Colaborador | Ve y actualiza lo asignado a él (actividades/subtareas propias), comenta |
@@ -25,7 +26,16 @@ tiene cada cosa — sin que cargar la información sea tedioso para quien lo usa
 
 ### 1. Seguridad
 - Login/logout con JWT, sesión persistida en el navegador.
-- Usuarios: alta/edición por el Administrador (nombre, email, rol, departamento, cargo, activo/inactivo).
+- Usuarios: alta/edición directa por el Administrador (nombre, email, rol, departamento, cargo,
+  activo/inactivo) **o** autorregistro público (`/registro`) con doble candado: el propio usuario
+  confirma su correo (enlace de un solo uso, vence en 24h) y luego un Administrador/Super
+  Administrador aprueba la cuenta (elige rol y departamento) o la rechaza. El primer usuario que
+  exista en el sistema se vuelve Super Administrador automáticamente, sin correo ni aprobación.
+- Recuperación de clave (`/olvide-clave` → `/restablecer-clave`): respuesta siempre genérica
+  (no revela si el correo existe), enlace de un solo uso que vence en 1 hora.
+- Correo saliente (verificación/recuperación): SMTP configurable desde Configuración por el Super
+  Administrador; sin configurar, el sistema sigue funcionando en modo dev (el enlace se loguea en
+  vez de enviarse por correo real).
 - Auditoría central (`audit_log`): quién hizo qué, sobre qué entidad, cuándo.
 
 ### 2. Organización
@@ -71,6 +81,9 @@ tiene cada cosa — sin que cargar la información sea tedioso para quien lo usa
 - Catálogos editables por el Administrador: estados de proyecto, estados de actividad, prioridades,
   tipos de proyecto, departamentos. Vienen con datos semilla — no requieren configuración inicial.
 - Preferencias de interfaz: idioma es-EC/en-US, tema claro/oscuro, apariencia de botones.
+- Correo (SMTP) — visible y editable **solo** por el Super Administrador: host, puerto, usuario,
+  remitente y clave (la clave se guarda cifrada y nunca se vuelve a mostrar, solo se sabe si está
+  "configurada" o no).
 
 ## Flujos clave