Fix: mejoras del modelo de datos (recordatorios, roles base, PK de comentarios, auditoría)

Qué y por qué

Revisión del documento de BD (Etapa 3) contra el schema real: se resuelven los pendientes de la sección 7.3 y algunos bugs que aparecieron en la revisión.

Bugs

• No se podía marcar como cumplido un recordatorio vencido (RF27). El CHECK chk_fec_hora_futura se reevaluaba en cada UPDATE, así que con la fecha pasada la base rechazaba cualquier cambio. Se reemplaza por el trigger trg_validar_fec_hora_futura, que exige fecha futura solo al crear o al cambiar fec_hora.
• El reporte siempre contaba 0 recordatorios vencidos. estado_operativo solo se calculaba al escribir la fila, así que quedaba en FUTURO para siempre. Se agrega la función recalcular_estados_operativos(), que EstadoOperativoScheduler ejecuta cada medianoche y al arrancar.
• Se podían inscribir estudiantes en grupos de una carrera dada de baja (regla 2.10). EstudianteService ahora lo rechaza con 422.

Mejoras del modelo

• id_neg_recordatorio: UNIQUE y CHECK de formato REC-AAAA-NNNNNN (pendiente de la devolución de la Etapa 1).
• Roles ADMINISTRADOR y ESTUDIANTE protegidos también en la base (trg_proteger_roles_base): no se pueden editar, desactivar, borrar ni quitarles permisos por fuera de la API. Agregarles permisos sigue permitido.
• PK simple en estu_obs_comentarios, estu_obs_confidenciales e inst_com_confidenciales: la PK compuesta incluía un SERIAL que ya es único. ComentarioConfidencialInstancia deja de usar @EmbeddedId (igual que ComentarioNormalInstancia).
• ON DELETE CASCADE → RESTRICT en las FKs de comentarios: borrar físicamente un funcionario o estudiante se llevaba sus comentarios, en contra de la baja solo lógica.
• La auditoría guarda completo el contenido de los comentarios confidenciales. Antes se omitía y se perdía el historial, sin proteger nada: la auditoría solo la consulta el ADMINISTRADOR.

Cambios

• proyecto_schema.sql: triggers y funciones nuevas, constraints, PKs y FKs.
• EstadoOperativoScheduler (nuevo) + RecordatorioRepository.recalcularEstadosOperativos().
• ComentarioConfidencialInstancia (entidad, repositorio, service, mapper) con @Id simple.
• EstudianteService.asignarGrupos: valida que la carrera del grupo esté activa.
• Tests: EstadoOperativoSchedulerTest (nuevo), caso nuevo en EstudianteServiceTest; ajustes en los tests de comentarios confidenciales de instancia.

Cómo probar

1. Recrear la base: docker compose down -v && docker compose up -d.
2. ./mvnw test (890 tests, todos pasan). Los IT también pasan contra una base con el schema nuevo.
3. Crear un recordatorio con fecha cercana, esperar a que venza y marcarlo como cumplido: antes fallaba, ahora pasa. Al reiniciar la app pasa a VENCIDO.
4. Intentar asignar a un estudiante un grupo de una carrera inactiva → 422.
5. En la BD: UPDATE proyecto.roles SET estado = 'INACTIVO' WHERE nom_rol = 'ADMINISTRADOR'; → error.

Cambios en BD

ddl-auto=validate no los aplica. En bases existentes hay que recrear la base o correr la migración migracion_bd_mejoras_etapa3.sql (dentro de Drive queda el archivo):

docker exec -i sienep-db psql -U sienep -d sienep -v ON_ERROR_STOP=1 < migracion_bd_mejoras_etapa3.sql

Antes de correrla, verificar que no haya ids de negocio duplicados (debe devolver 0 filas):

SELECT id_neg_recordatorio FROM proyecto.recordatorios GROUP BY 1 HAVING count(*) > 1;