P0 contexto: ventana por modelo + recuperación ante overflow + self-heal del catálogo

Que las conversaciones largas no se rompan ni gasten de más:

Ventana de contexto por modelo (antes: budget estático 120k/200k para todos):
- cost.resolve_context_window: lee context_length del catálogo OpenRouter/DeepSeek
  en Redis, con fallback a litellm. config.budget_for_window deriva el budget de
  la ventana real (window - max_output - reserve). build_context lo aplica por
  turno (param model_id) en vez del fijo de settings.
- Self-heal del catálogo OpenRouter: el admin panel lo cachea con TTL 1h y solo lo
  repuebla al abrir su ventana de IA → en runtime caducaba y se perdían ventana y
  precio. Ahora cost._get_catalog lo refresca solo (fetch público, mismo shape,
  cooldown 5min, TTL 24h). Arregla también el coste (caía al fijo).

Recuperación ante overflow:
- adapters.base.ContextOverflowError; openai_adapter traduce el error de
  context-length del proveedor (init e iteración del stream).
- base.py: retry proactivo que recompacta hasta caber en la ventana ANTES de
  llamar al LLM; si ni así cabe → error accionable (no rompe la sesión).
- engine.py: mensaje user-facing claro (modelo + ventana).

Tests: ventana/budget, self-heal (mockeado), overflow, y sesión REAL de Redis. 106 verdes.

evals/: harness para evaluar al agente acai-code (driver + README + resultados).
Comparativa kimi vs deepseek vs glm (deepseek-v4-pro high = mejor calidad/precio).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

evals/README.md

@@ -0,0 +1,43 @@
+# Evals del agente acai-code
+
+Harness para evaluar el comportamiento del agente IA (`acai`) montando una
+landing real con módulos gestionables, capturando cada turno (thinking, tool
+calls, resultados, errores). Sirve para **comparar entre modelos** y discernir
+si un fallo es del **modelo** o de la **documentación/KB** (mismo flujo, mismo
+proyecto, distinto modelo → ¿cambian los errores?).
+
+## Cómo correrlo
+
+1. Elige el modelo activo en el **Forge Admin Panel → ventana de IA** (provider +
+   modelo + reasoning). El catálogo OpenRouter se auto-repuebla en runtime aunque
+   caduque (ver `orchestrator/cost.py: _get_catalog`).
+2. Usa un proyecto **en modo TEST** (no producción) — el agente escribe módulos/
+   records reales en la copia forge-local. Nunca corras esto contra producción.
+3. Lanza cada turno con el driver, reutilizando el `session_id` que devuelve el
+   primer turno para mantener la MISMA conversación:
+
+```bash
+NET=acai-vscode-plugin_acai-net   # red docker del compose
+docker run --rm --network $NET \
+  -v "$PWD/agenticSystem/evals:/data" -v "$PWD/agenticSystem/evals/logs:/logs" \
+  -e EVAL_PROJECT=empleo.cocosolution.com \
+  -w /data acai-vscode-plugin-agentic \
+  python /data/driver.py "Móntame una sección de beneficios con 3 tarjetas"
+
+# turno 2 (reusa el SESSION_ID del turno 1):
+docker run ... python /data/driver.py "Ahora una sección de equipo con fotos y enlaces" "<SESSION_ID>"
+```
+
+- El log completo (en vivo) se acumula en `evals/logs/session.log`.
+- El driver autentica con `X-Acai-User` hiteando `app:9091` directo en la red
+  interna (somos superadmin en infra de confianza).
+
+## Métricas que captura
+
+- nº de tool calls, errores (`success:false`, HTTP_4xx), tools repetidas (señal
+  de bucle), tokens de input/output (coste del thrashing).
+
+## Resultados
+
+Ver [`results-landing-build.md`](./results-landing-build.md) — un apartado por
+modelo, para comparar.