Feature: verificar procesos abiertos antes de la baja de un estudiante (RF06)

Qué se hizo

Antes de dar de baja a un estudiante, el sistema ahora verifica si tiene procesos abiertos y, si los tiene, exige confirmar la baja. Es lo que pide el RF06 en su validación: "Verificación de inexistencia de procesos críticos abiertos".

Por qué

DELETE /estudiantes/{id} daba la baja sin revisar nada. Un estudiante con reuniones agendadas o recordatorios pendientes podía quedar inactivo sin que nadie lo advirtiera.

Qué cuenta como "proceso abierto"

• Instancias futuras: instancias activas del estudiante con fecha y hora posteriores a ahora.
• Recordatorios pendientes: recordatorios activos, no cumplidos, desde el inicio del día de hoy en adelante, de instancias del estudiante. Se calcula por fecha y no por estado_operativo, porque esa columna la recalcula el trigger solo cuando se escribe el recordatorio y con los días queda desactualizada.
• No cuentan las incidencias (registran algo que ya pasó), ni lo pasado, lo cumplido o lo inactivo.

Cambios

• GET /estudiantes/{id}/procesos-abiertos (nuevo, requiere DESACTIVAR_ESTUDIANTE): devuelve { instanciasFuturas, recordatoriosPendientes }. El frontend lo usa para mostrar el aviso antes de confirmar.
• DELETE /estudiantes/{id}: si hay procesos abiertos responde 409 con el detalle (ej. "El estudiante tiene 2 instancias agendadas y 1 recordatorio pendiente. Confirmá la baja para continuar."), salvo que llegue ?confirmar=true. Sin procesos abiertos se comporta igual que antes. La verificación está en el servidor, así el aviso no depende de que el cliente lo muestre.
• Los procesos no se cancelan al dar la baja: es lógica y el historial se conserva.
• ProcesosAbiertosDTO (nuevo) y dos consultas de conteo: InstanciaComunRepository.contarFuturasDelEstudiante y RecordatorioRepository.contarPendientesDelEstudiante.

Tests

• EstudianteServiceTest:
  • sin procesos, da la baja sin pedir confirmación;
  • con procesos y sin confirmar, responde 409 con el detalle y no da la baja;
  • confirmado, da la baja;
  • el conteo de recordatorios arranca a las 00:00 de hoy;
  • 404 si el estudiante no existe.
• EstudianteControllerTest: confirmar llega al servicio (false por defecto), el 409 se propaga, y el GET devuelve los conteos.
• EstudianteProcesosAbiertosIT (nuevo, contra Postgres real): arma instancias y recordatorios de todos los tipos y verifica que se cuenten solo los que corresponden (no los pasados, cumplidos, inactivos ni los de otro estudiante), y que la baja sin confirmar responda 409. No corre con ./mvnw test, igual que los otros IT; se corre con:

  docker compose up -d
  ./mvnw test -Dtest=EstudianteProcesosAbiertosIT -Dspring.profiles.active=integration

• ./mvnw test: pasan los 787 tests.

Cómo probar

1. Elegir un estudiante con una instancia agendada a futuro.
2. GET /estudiantes/{id}/procesos-abiertos → instanciasFuturas: 1.
3. DELETE /estudiantes/{id} → 409 con el detalle; el estudiante sigue activo.
4. DELETE /estudiantes/{id}?confirmar=true → 204; queda inactivo, y la instancia sigue en su historial.
5. Un estudiante sin procesos abiertos → DELETE sin parámetro da la baja como siempre.

🗄️ Cambios en la base de datos

Ninguno.

Compatibilidad

• No choca con los otros MRs abiertos.
• Cambio de comportamiento: un cliente que haga DELETE sobre un estudiante con procesos abiertos va a recibir 409 hasta que mande confirmar=true. El frontend lo maneja en su MR "avisar procesos abiertos antes de dar de baja".