Fix: el alta y la edición de grupo avisan cuando ya existe un grupo inactivo igual

Qué

Al crear un grupo con el mismo nombre, carrera y generación que uno inactivo, o al renombrar un grupo con esos datos, el backend ahora responde 409 con un mensaje que dice que el grupo existente está inactivo. Surge de la ejecución del CP-762 en la Entrega 3 (no tiene Mantis).

Por qué

La restricción uk_grupo_carrera_grupo_generacion no distingue activos de inactivos, pero el service solo revisaba los activos. Repetir el nombre de un grupo inactivo pasaba esa validación, lo rechazaba la base y volvía como "La operación no pudo completarse por un conflicto con datos existentes.", que el frontend mostraba como "Ya hay un grupo activo…" aunque no hubiera ninguno activo.

El equipo decidió mantener la restricción: no se admiten dos grupos iguales, estén activos o no. Si el grupo existe inactivo, se reactiva.

Cambios

• GrupoService.crear: si existe un grupo inactivo igual, responde 409 con "Ya existe un grupo inactivo con ese nombre para esa carrera y generación. Se puede reactivar en lugar de crear otro."
• GrupoService.editar: mismo chequeo, con "Ya existe un grupo inactivo con ese nombre para esa carrera y generación."
• GrupoRepository: nuevo existsByNomGrupoAndCarreraIdCarreraAndGeneracionAndEstado. Compara el nombre exacto, igual que la restricción de la tabla.
• Tests: dos casos nuevos en GrupoServiceTest (alta y edición con un inactivo igual).

No cambia la validación contra grupos activos ni la de reactivar.

Cómo probar

1. Crear el grupo "QA-4" (Analista en TI, 2025) y desactivarlo.
2. POST /grupos con los mismos datos: responde 409 con el mensaje que indica reactivarlo.
3. Reactivar el "QA-4" original: responde bien y queda activo.
4. Con "QA-4" inactivo, editar otro grupo activo de la misma carrera y generación y ponerle "QA-4": responde 409 con el mensaje de grupo inactivo.

Tests: ./mvnw test -Dtest='Grupo*Test'

Cambios en BD

Ninguno.