feat(alertas): el alertamiento reporta en Logs del sistema por qué no salió un correo

Averiguar en QA por qué una alarma mandó campana pero no correo costó revisar seis compuertas y pedir acceso por SSH al servidor. La causa era un ajuste que se ve y se mueve desde /admin/parametros. Nada de eso tenía por qué salir de la pantalla.

Tres de las seis compuertas de _emit_email hacían return pelón: un correo que no sale porque el interruptor está apagado se veía igual que uno bloqueado porque el destinatario no tiene correo capturado, e igual que uno que sí salió. Ahora cada una devuelve su estado —enviado, canal_solo_campana, interruptor_apagado, fusible_entorno, sin_destinatarios, sin_correo_valido, excluidos_infra, smtp_fallo— con el texto de qué hacer.

El estado viaja en una bitácora opcional de _emit hasta scheduler_logs.result_json. Opcional a propósito: _emit ya tenía tres llamadores y cambiarle el tipo de retorno los rompía.

Las corridas manuales («probar regla», «correr evaluadora») no se registraban en ningún lado: el resultado moría al cerrar la pestaña. Ahora escriben en scheduler_logs con trigger_type=manual y quién las lanzó, así que la prueba que acabas de correr aparece junto a las del cron.

En /admin/logs el renglón se despliega. result_json se guardaba desde siempre y no se pintaba nunca, así que una corrida que emitió cuatro alertas sin mandar un correo se veía idéntica a una que mandó los cuatro. Los jobs que no son de alertas caen al JSON crudo en vez de inventarles una interpretación.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com Claude-Session: https://claude.ai/code/session_01Dy1oTZc5vwiws7EFFQwnHF