feature/cras-update-in-place (#22)

Reviewed-on: #22
Co-authored-by: hreyes <hreyes@aduanasoft.com.mx>
Co-committed-by: hreyes <hreyes@aduanasoft.com.mx>

src/lib/server/service-auth.ts

@@ -8,6 +8,7 @@
  */
 import { timingSafeEqual } from 'node:crypto';
 import { env } from '$env/dynamic/private';
+import { logger } from './logger';
 
 /**
  * Valida el header Authorization: Bearer <token> contra CLOUDRESTORE_API_TOKEN.
@@ -38,3 +39,35 @@ export function checkServiceToken(request: Request): { ok: true } | { ok: false;
     }
     return { ok: true };
 }
+
+/**
+ * Registra un rechazo de token de servicio.
+ *
+ * Hasta ahora un 401 no dejaba **ni una línea** en el panel: solo se logueaba el 500 de "token no
+ * configurado". Con el token rotado, todos los agentes quedan mudos —dejan de reportar versión, de
+ * resolver rutas y de registrar resultados— y desde el panel eso se ve igual que un agente
+ * apagado. Peor: el `trace_id` que se le devuelve al agente en el cuerpo del 401 no existía del
+ * lado del servidor, así que era imposible de correlacionar.
+ *
+ * NUNCA se registra el token ni un fragmento suyo. Lo que sirve para diagnosticar es qué ruta se
+ * rechazó, si venía con header o sin él, y de qué instancia.
+ */
+export function logServiceTokenRejected(info: {
+    traceId: string;
+    route: string;
+    request: Request;
+    instanceKey?: string | null;
+}): void {
+    const header = info.request.headers.get('authorization') ?? '';
+    logger.warn({
+        trace_id: info.traceId,
+        message: 'Token de servicio rechazado',
+        context: {
+            route: info.route,
+            // Distinguir "no mandó header" de "mandó uno que no cuadra" separa un agente sin
+            // configurar de un token rotado, que son dos problemas con remedios distintos.
+            reason: header ? 'token no coincide' : 'sin header Authorization',
+            instance_key: info.instanceKey?.trim() || null
+        }
+    });
+}