fix: los cuatro hallazgos reales de la revision con IA

- crearTurno verificaba disponibilidad y creaba el turno en dos operaciones
  sueltas: dos clientes podian pasar la verificacion a la vez y sobrevender el
  mismo horario. Ahora va todo en una transaccion, serializada por jefe con
  pg_advisory_xact_lock. slotEstaDisponible acepta el cliente de la transaccion.
  Probado contra un Postgres real: 5 reservas simultaneas del mismo slot con
  capacidad 1 dan 1 ok + 4 conflictos y una sola fila; sacando el lock, entran
  las 5.
- La deduplicacion del webhook estaba en memoria y solo servia con una
  instancia. Pasa a la base con el modelo MensajeWhatsappProcesado: el insert
  del id es atomico por el indice unico, asi que aguanta reintentos
  concurrentes de Meta (verificado). Se limpian los ids de mas de 7 dias.
- postMensaje no reintentaba: ahora reintenta 3 veces ante 429, 5xx y fallas
  de red, con backoff exponencial y jitter. Un 4xx nuestro no se reintenta.
- /api/cliente/servicios devolvia los trabajos de un jefe dado de baja; ahora
  responde 404 si el jefe no existe o no esta activo.

test:envio suma los casos de reintento (35 asserts). El Prisma en memoria del
test del bot ahora entiende $transaction y $executeRaw.

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

src/app/api/cliente/servicios/route.ts

@@ -13,6 +13,14 @@ export async function GET(req: NextRequest) {
   if (!jefeMecanicoId)
     return NextResponse.json({ error: "jefeMecanicoId requerido" }, { status: 400 });
 
+  // Un jefe dado de baja no debe exponer sus trabajos (ni dejar arrancar una reserva).
+  const jefe = await prisma.jefeMecanico.findUnique({
+    where: { id: jefeMecanicoId },
+    select: { activo: true },
+  });
+  if (!jefe || !jefe.activo)
+    return NextResponse.json({ error: "Jefe mecánico no disponible" }, { status: 404 });
+
   const servicios = await prisma.tipoServicio.findMany({
     where: whereTrabajosDeJefe(jefeMecanicoId),
     orderBy: { nombre: "asc" },