feat(umind): el correo entra al agente por dos puertas distintas — y son distintas a propósito

En "Dónde atiende", el canal correo: el agente lee una casilla y responde solo
los correos que llegan, con su base de conocimiento, igual que atiende WhatsApp.
Como el correo no tiene webhook, se revisa por intervalo — y el intervalo lo
elige el cliente por canal (2 a 60 minutos): una inmobiliaria quiere 2, a un
estudio contable con 30 le sobra. El cron corre cada minuto pero cada casilla
se revisa solo cuando le toca, con un pool de 8 para que 100 casillas no salgan
a la red en el mismo instante.

Las guardas que separan "asistente" de "incidente", cada una con su test:
nunca responde correo automático ni se responde a sí mismo (el bucle con otro
autoresponder); la revisión se marca ANTES de conectar, así una contraseña
cambiada no martilla el login cada minuto hasta que el host del cliente nos
bloquea; y el correo se marca leído recién cuando la respuesta salió — si el
envío falla, queda sin leer y se reintenta.

En "Lo que sabe", las cuentas de correo: casillas que el agente consulta a
pedido — "revisame los correos de hoy y haceme un resumen" — sin nada de fondo.
Solo lectura en serio: Peek, INBOX en read-only, y un test que falla si alguien
le agrega un marcado. Ahora se pueden conectar varias por agente; con más de
una, el modelo pregunta cuál en vez de adivinar — resumirle a alguien la
casilla que no pidió no es un error menor. El alta pide correo y contraseña:
el host se deduce (mail.<dominio>) y el campo técnico aparece recién si eso
falla. Se prueba la conexión antes de guardar, con la persona mirando.

Enviar por una cuenta conectada está bloqueado a propósito: para responder
correos está el canal, con sus guardas. Una tool de envío sin límites es una
máquina de spam con el dominio del cliente.

La navegación acompaña: "Lo que sabe" agrupa Información, Cuentas de correo y
Herramientas — tres formas de saber, no tres pantallas sueltas — y Avanzado
queda solo con Problemas.

El SMTP se unificó en una sola implementación que comparten soporte y el canal:
el bug de STARTTLS que abría dos conexiones ya se pagó una vez.

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

pkg/models/umind_canal.go

@@ -4,6 +4,7 @@ import (
 	"crypto/rand"
 	"encoding/hex"
 	"fmt"
+	"time"
 
 	"github.com/sujit-baniya/fiber-boilerplate/app"
 	"gorm.io/gorm"
@@ -36,6 +37,32 @@ type UmindCanal struct {
 	// Documentos adjuntos (PDF, Word, texto): se les extrae el contenido y se
 	// le pasa al agente como si el cliente lo hubiera escrito.
 	UsarArchivosDocs bool `json:"usar_archivos_docs" gorm:"column:usar_archivos_docs;default:false"`
+	// Solo para el canal correo: cada cuántos minutos se revisa la casilla.
+	// Lo elige el cliente — una inmobiliaria quiere 2, un estudio contable con
+	// 30 le sobra. Telegram y WhatsApp no lo usan: a ellos les llega webhook.
+	IntervaloMinutos int `json:"intervalo_minutos" gorm:"column:intervalo_minutos;default:5"`
+	// UltimaRevision es lo que decide si ya le toca — en la base y no en
+	// memoria, por la misma razón que el aviso de tope: los despliegues borran
+	// la RAM varias veces por día.
+	UltimaRevision *time.Time `json:"ultima_revision" gorm:"column:ultima_revision"`
+}
+
+// MarcarRevisionCanal deja constancia de que la casilla se acaba de revisar.
+func MarcarRevisionCanal(id uint) {
+	ahora := time.Now()
+	app.Http.Database.DB.Model(&UmindCanal{}).Where("id = ?", id).
+		Update("ultima_revision", &ahora)
+}
+
+// GetCanalesCorreoPendientes devuelve los canales de correo activos a los que
+// ya les toca revisión según su propio intervalo.
+func GetCanalesCorreoPendientes() ([]UmindCanal, error) {
+	var items []UmindCanal
+	err := app.Http.Database.DB.
+		Where("tipo = ? AND activo = ?", "correo", true).
+		Where("ultima_revision IS NULL OR ultima_revision < NOW() - (intervalo_minutos || ' minutes')::interval").
+		Find(&items).Error
+	return items, err
 }
 
 func (UmindCanal) TableName() string { return "umind_canales" }