feat(umind): el agente programa recordatorios, y solo para su dueño

"Avisame el 15 de marzo que vence la póliza de Acme, y todos los años" queda
programado desde la conversación, visible y cancelable en el panel. Tres tools:
programar, listar, cancelar.

El aviso vuelve por donde se pidió — Telegram a ese chat, correo a esa casilla
— o al dueño del espacio por correo y campanita. Nunca a una dirección que
dicte la conversación: eso sería un cañón de spam con destinatario libre.

Y las tools de aviso solo se le OFRECEN al modelo cuando la sesión es interna:
el chat de prueba del panel (que corre autenticado) o un canal marcado como
línea privada del dueño. En el widget público escribe cualquiera, y cualquiera
no puede programarle recordatorios ni gastarle el plan a otro. El gate está en
dos capas: la tool no se declara, y si igual la pide, el ejecutor la rechaza.

Tres detalles que se pagan una sola vez:
- El cron corre en memoria del proceso, sin lock distribuido: con dos
  instancias cada aviso saldría dos veces. El reclamo es un UPDATE condicional
  — la base ya es el árbitro, no hace falta traer otro.
- Si el servidor estuvo caído, una repetición diaria se saltea los ciclos
  perdidos en vez de disparar diez avisos viejos de golpe.
- Un fallo de SMTP devuelve el aviso a pendiente: una caída de correo no puede
  perder un vencimiento de póliza.

Una fecha sin hora se entrega a las 9, no a medianoche, que es cuando nadie
mira el teléfono.

De paso: los archivos de los espacios uMind nunca se sirven por el estático de
/uploads. El guard genérico solo sabe si hay sesión de panel, no de quién es el
archivo — salen por su endpoint, que sí valida propiedad. Cerrado por
construcción y no por acordarse.

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

pkg/models/notif_config.go

@@ -11,11 +11,12 @@ import (
 // Define qué canales activar para cada combinación evento × destinatario.
 //
 // Eventos disponibles (extensibles):
-//   ticket_nuevo              → admin recibe cuando el cliente abre un ticket
-//   ticket_respuesta_cliente  → admin recibe cuando el cliente responde
-//   ticket_respuesta_admin    → portal_user recibe cuando admin responde
-//   factura_emitida           → portal_user recibe cuando se emite factura
-//   avance_publicado          → portal_user recibe cuando se publica avance
+//
+//	ticket_nuevo              → admin recibe cuando el cliente abre un ticket
+//	ticket_respuesta_cliente  → admin recibe cuando el cliente responde
+//	ticket_respuesta_admin    → portal_user recibe cuando admin responde
+//	factura_emitida           → portal_user recibe cuando se emite factura
+//	avance_publicado          → portal_user recibe cuando se publica avance
 //
 // Destinatarios: "admin" | "portal_user"
 type NotifEventoConfig struct {
@@ -168,11 +169,11 @@ func SaveServidorAlertaUmbral(cfg *ServidorAlertaUmbral) error {
 		return db.Create(cfg).Error
 	}
 	return db.Model(&existing).Updates(map[string]interface{}{
-		"activo":               cfg.Activo,
-		"minutos_sin_ping":     cfg.MinutosSinPing,
-		"umbral_cpu":           cfg.UmbralCPU,
-		"umbral_ram":           cfg.UmbralRAM,
-		"umbral_disco":         cfg.UmbralDisco,
+		"activo":                cfg.Activo,
+		"minutos_sin_ping":      cfg.MinutosSinPing,
+		"umbral_cpu":            cfg.UmbralCPU,
+		"umbral_ram":            cfg.UmbralRAM,
+		"umbral_disco":          cfg.UmbralDisco,
 		"dias_ante_vencimiento": cfg.DiasAnteVencimiento,
 	}).Error
 }