fix(soporte): aviso repetido en Telegram y el acuse al cliente que no salía

Telegram: los avisos se mandaban a todas las configuraciones activas sin mirar
a dónde apuntan. Con el mismo chat cargado en dos filas, cada aviso llegaba dos
veces. Ahora se manda una vez por destino (bot + chat); los chats distintos
siguen recibiendo todos.

Correo al remitente: el camino STARTTLS abría una conexión, hacía StartTLS,
autenticaba… y la descartaba para llamar a smtp.SendMail, que abre otra. La
primera quedaba colgada y el envío real salía por una conexión distinta, que
podía no estar autenticada. Reescrito: una sola conexión, asegurada según la
configuración, y cierre con QUIT.

Y como el acuse se manda en segundo plano, su error moría en el log. Ahora hay
un botón "Enviar correo de prueba" que usa exactamente el mismo camino y
devuelve el error del servidor en pantalla, y el último fallo del acuse real
aparece en el resultado de "Revisar buzón ahora".

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

pkg/services/notif_dispatch.go

@@ -412,10 +412,22 @@ func sendTelegramAdmin(mensaje string) {
 		log.Printf("[Notif] Error obteniendo configs telegram: %v", err)
 		return
 	}
+	// Un mismo chat puede estar cargado en más de una configuración (dos bots
+	// apuntando al mismo grupo, o la misma config duplicada). Sin esto, cada
+	// aviso llega repetido tantas veces como filas haya.
+	yaEnviado := map[string]bool{}
+
 	for _, cfg := range configs {
 		if !cfg.Activo {
 			continue
 		}
+		destino := cfg.BotToken + "→" + cfg.ChatID
+		if yaEnviado[destino] {
+			log.Printf("[Notif] Chat %s repetido en la config %d (%s), no se manda de nuevo", cfg.ChatID, cfg.ID, cfg.Nombre)
+			continue
+		}
+		yaEnviado[destino] = true
+
 		ts := &TelegramService{BotToken: cfg.BotToken}
 		sendErr := ts.SendMessage(cfg.ChatID, mensaje)
 		logEntry := &models.TelegramLog{