fix: cerrar el punto ciego de rechazos 400 en el guardrail de la rampa - #17

Resumen

• HALLAZGO REAL (auditoría de rigor arquitectónico, 2026-08-17, ver PLAN.md §3.5 y ADR-03): el guardrail de observe_and_guard solo filtraba success == false — ciego a una regresión de negocio real (un bug de despliegue que rechace con 400 solicitudes antes válidas). ValidatePayment maneja esos casos sin lanzar excepción, así que Application Insights los marca success=true sin importar el código HTTP. Verificado con 230+ solicitudes reales que nunca dispararon el guardrail pese a ser errores reales.
• Fix: compara la tasa de 400 de la instancia en rampa contra la del otro rol en la misma ventana de 5 min (misma mezcla real de tráfico) — diferencia >10 puntos porcentuales con piso mínimo de 3 solicitudes rechazadas dispara el mismo rollback ya existente.
• Brecha reconocida y documentada, no cerrada en este PR: la alerta asíncrona de Azure Monitor (rollback-canary, novapay-iac-terraform) mantiene la misma limitación (solo 5xx) — su propósito es cubrir el caso en que el job de CD no está disponible, escenario distinto.

Test plan

• bash -n sobre el script — sintaxis válida.
• Revisión manual de la lógica contra el caso real que la motivó (el mismo tipo de tráfico forzado con ERROR_RATE_PCT=100 del load-generator ahora sí sería detectado, dado que produce una diferencia de tasa de rechazo entre roles).
• Próximo ciclo de rampa real end-to-end con esta lógica activa (pendiente, no bloqueante para este fix).

🤖 Generated with Claude Code