feat(notificaciones): global send flags + editable schedules

The "Flags del envío" panel lived inside the Servicios tab and only
governed the four bulk jobs. The pólizas half had no debug at all, so
there was no way to test a renewal notice without mailing a real
customer. The panel now lives in the /notificaciones shell above the
tabs and both halves read it.

`debug` on the renewal path diverts to the same override inbox as the
servicios jobs and deliberately does NOT write the `RenewalNotice` row
or advance the sweep's `lastSuccessfulAt` — the customer was not
notified, so nothing may gate the letter they are still owed.
`ignoreDayRestriction` and `useEmailLimit` stay estado-de-cuenta-only
and are labelled as such.

Both automatic sweeps are now operator-editable. The renewal cadence
was a `@Cron("0 6 * * *")` literal and servicios had no automatic run
at all; both now resolve through `NotificationScheduleService`, which
stores the cadence in `app_settings` and reinstalls the cron job on
save — no redeploy, no restart. Defaults preserve current behaviour:
pólizas 06:00 daily, servicios off. A scheduled run never inherits the
UI flags; it always sends for real.

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

apps/web/src/components/NotificacionesPolizas.tsx

@@ -4,7 +4,7 @@ import { useCallback, useEffect, useState } from "react";
 import { useCan } from "@/lib/abilities";
 import { formatDate, formatMoney } from "@/lib/labels";
 import { NotificationLogPanel } from "@/components/NotificationLogPanel";
-import { apiFetch, POLIZAS_LOG_SCOPE } from "@/lib/api";
+import { apiFetch, POLIZAS_LOG_SCOPE, type NotificationFlags } from "@/lib/api";
 
 /**
  * Renewal notices — the "Pólizas" half of /notificaciones. Shows which
@@ -17,6 +17,11 @@ import { apiFetch, POLIZAS_LOG_SCOPE } from "@/lib/api";
  * reads, so "Registro de envíos" below is the same component with the
  * POLICIES slice — failures and no-email skips included, which the pending
  * list alone cannot show.
+ *
+ * `debug` comes from the shared flags card above the tabs and means the same
+ * thing here as it does for servicios: the mail is diverted to the override
+ * inbox. It additionally does NOT mark the notice as sent, so a test send
+ * leaves the row exactly where it was — pending.
  */
 
 export interface RenewalLetter {
@@ -40,12 +45,15 @@ export interface RenewalSweepResult {
   skipped: number;
   failed: number;
   failures: { policyId: string; generation: number; error: string }[];
+  debug: boolean;
 }
 
 export interface RenewalSendResult {
   policyId: string;
   generation: number;
+  /** Where the mail actually went — the override inbox under debug. */
   to: string;
+  debug: boolean;
   sentAt: string;
   providerMessageId?: string;
 }
@@ -56,8 +64,9 @@ const GENERATION_LABEL: Record<number, string> = {
   3: "Tercer aviso (7 días después)",
 };
 
-export function NotificacionesPolizas() {
+export function NotificacionesPolizas({ flags }: { flags: NotificationFlags }) {
   const allowed = useCan("renewal:send");
+  const debug = !!flags.debug;
   const [days, setDays] = useState(30);
   const [pending, setPending] = useState<RenewalLetter[] | null>(null);
   const [pendingError, setPendingError] = useState<string | null>(null);
@@ -89,14 +98,28 @@ export function NotificacionesPolizas() {
   }, [allowed, refresh]);
 
   async function handleSweep() {
+    // Only worth confirming when debug is off — that is the case where real
+    // customers receive mail. Mirrors "Ejecutar todos" on the servicios tab.
+    if (!debug) {
+      const ok = window.confirm(
+        "debug está desactivado: los avisos irán a los correos reales de los clientes. ¿Ejecutar el barrido?",
+      );
+      if (!ok) return;
+    }
     setActionError(null);
     setNotice(null);
     setSweeping(true);
     try {
       const result = await apiFetch<RenewalSweepResult>("/renewals/sweep", {
         method: "POST",
+        body: JSON.stringify({ debug }),
       });
-      setNotice(`Enviados ${result.sent} avisos (${result.failed} con error).`);
+      setNotice(
+        `Enviados ${result.sent} avisos (${result.failed} con error).` +
+          (result.debug
+            ? " Modo debug: fueron al buzón de pruebas y siguen pendientes."
+            : ""),
+      );
       setLogToken((t) => t + 1);
       await refresh();
     } catch (e) {
@@ -122,9 +145,14 @@ export function NotificacionesPolizas() {
         body: JSON.stringify({
           policyId: letter.policyId,
           generation: letter.generation,
+          debug,
         }),
       });
-      setNotice(`Aviso enviado a ${result.to}.`);
+      setNotice(
+        result.debug
+          ? `Prueba enviada a ${result.to}. El aviso sigue pendiente: el cliente no ha recibido nada.`
+          : `Aviso enviado a ${result.to}.`,
+      );
       setLogToken((t) => t + 1);
       await refresh();
     } catch (e) {
@@ -156,10 +184,10 @@ export function NotificacionesPolizas() {
   return (
     <div style={{ display: "grid", gap: 20 }}>
       <p className="muted" style={{ maxWidth: 760, margin: 0 }}>
-        El sistema ejecuta un barrido diario a las 06:00 hora local que notifica
-        a los clientes a 30, 15 y 7 días antes o después del vencimiento de su
-        póliza. Esta sección muestra qué avisos están pendientes y permite
-        ejecutarlo manualmente.
+        El sistema ejecuta un barrido automático (ver «Programación de envíos»
+        arriba) que notifica a los clientes a 30, 15 y 7 días antes o después
+        del vencimiento de su póliza. Esta sección muestra qué avisos están
+        pendientes y permite ejecutarlo manualmente.
       </p>
 
       {actionError && <div className="state-box state-error">{actionError}</div>}