Rediseñar auth a login de suscripción y corregir bugs de la prueba e2e

Auth: ANTHROPIC_API_KEY_FILE queda vacío por defecto — claude -p usa el
login de suscripción ya activo (~/.claude/.credentials.json) en vez de
una API key root-only. Se descartó ese diseño en vivo al confirmar que
no había API key real disponible; además elimina la necesidad de crear
secretos root-only vía sudo. Consecuencia: el futuro servicio systemd
debe correr como devops, no root. CLAUDE_BIN/KUBECTL_BIN se agregan por
ruta absoluta (ninguno está en el PATH de root/systemd).

Bugs encontrados y corregidos durante la prueba end-to-end contra el
cluster real (deployment canario desechable):
- execute_corrective_action se invocaba en un subshell ($()), perdiendo
  sus variables de resultado (LAST_ACTION_*) -> crash "unbound
  variable". Ahora usa el exit status de la función, invocada directo.
- DRY_RUN marcaba blocked=true en state.json como si la acción hubiera
  sido real, contaminando una corrida real posterior sobre el mismo
  recurso. Ahora el estado solo se actualiza fuera de DRY_RUN.

También: GITEA_TOKEN_FILE pasa a /DATA (dueño devops, sin sudo), y
media.cruzcloud.net se excluye de PUBLIC_DOMAINS (uso personal, no es
parte del lab).

Prueba e2e completa documentada en apps-registry:
docs/arquitectura/agente-monitoreo.md.

lab-agent/README.md

@@ -1,17 +1,17 @@
-# lab-agent — agente de diagnóstico/corrección del lab (Paso 2)
+# lab-agent — agente de diagnóstico/corrección del lab
 
 Wrapper headless que corre `claude -p` para diagnosticar el estado del
 lab (kubectl, docker, curl a endpoints públicos, API de Gitea Actions) y,
 solo para un conjunto explícito y aprobado de recursos, ejecutar una
-acción correctiva de bajo riesgo. Ver la lista blanca completa y su
-justificación de gobernanza en
-`apps-registry` → `docs/arquitectura/agente-monitoreo.md` (Paso 6,
-pendiente de escribir).
+acción correctiva de bajo riesgo. Ver la lista blanca completa, la
+justificación de gobernanza y la evidencia de la prueba end-to-end en
+`apps-registry` → `docs/arquitectura/agente-monitoreo.md`.
 
-Este documento cubre solo el Paso 2 (el script). Los Pasos 3
-(notificaciones), 4 (systemd timer) y 5 (prueba controlada) son
-posteriores y requieren tu confirmación explícita antes de activarse en
-continuo — ver instrucciones al final.
+**Estado (2026-08-26): script y prueba end-to-end validados en vivo**
+contra el cluster real (deployment canario desechable, ciclo completo
+DRY_RUN → ejecución real → rate limit/bloqueo → limpieza). El timer de
+systemd (Paso 4) **todavía no está activo** — pendiente de tu
+confirmación explícita.
 
 ## Diseño de seguridad (por qué Claude no ejecuta comandos directamente)
 
@@ -98,45 +98,42 @@ cp lab-agent.env.example lab-agent.env
 # host distinto termine commiteada)
 ```
 
-Dos archivos root-only que este script espera pero **no crea** (por
-diseño — la creación de credenciales no se hace desde una sesión
-interactiva de Claude Code en este lab, ver política del proyecto):
+**Autenticación de `claude -p`:** `ANTHROPIC_API_KEY_FILE` queda vacío
+por defecto — el script usa el login de suscripción ya activo del
+usuario que lo corre (`~/.claude/.credentials.json`), no una API key
+aparte. Por eso el servicio systemd (cuando se active) debe correr
+como `devops`, no como `root`. Ver la sección "Autenticación" en
+`docs/arquitectura/agente-monitoreo.md` para el porqué completo.
+
+El único secreto real es `GITEA_TOKEN_FILE` (opcional, token de Gitea
+Actions con scope lectura) — dueño `devops`, sin sudo:
 
 ```bash
-sudo mkdir -p /etc/claude-lab-agent/secrets
-sudo tee /etc/claude-lab-agent/secrets/anthropic_api_key >/dev/null   # pega la key, Ctrl-D
-sudo tee /etc/claude-lab-agent/secrets/gitea_token >/dev/null         # token con scope read:repository (actions)
-sudo chown root:root /etc/claude-lab-agent/secrets/*
-sudo chmod 600 /etc/claude-lab-agent/secrets/*
+mkdir -p "$(dirname "$GITEA_TOKEN_FILE")"   # por defecto: /DATA/AppData/k3d-lab/lab-agent/secrets/
+echo "<tu-token>" > "$GITEA_TOKEN_FILE"
+chmod 600 "$GITEA_TOKEN_FILE"
 ```
 
-`GITEA_TOKEN_FILE` es opcional: si no existe, el agente sigue
-funcionando pero pierde la señal de "runner atascado" vía API de Gitea
-Actions (solo detecta el contenedor caído/reiniciando).
+Si no existe, el agente sigue funcionando pero pierde la señal de
+"runner atascado" vía API de Gitea Actions (solo detecta el contenedor
+caído/reiniciando).
 
-## Probar (Paso 2 — humo, sin secretos)
+## Probar
 
 ```bash
-./lab-agent.sh --dry-run
+./lab-agent.sh --dry-run   # simulación, no toca el cluster
+./lab-agent.sh --live      # ejecución real
 ```
 
-Ya validado en vivo 2026-08-25 hasta el paso de invocar `claude -p`
-(falla ahí, correctamente, por falta de
-`ANTHROPIC_API_KEY_FILE` — comportamiento esperado sin el secreto
-configurado). El diagnóstico de los 3 deployments de `ecommerce`,
-`gitea-runner` y los 5 dominios públicos funcionó correctamente contra
-el cluster real.
+Validado en vivo 2026-08-26 con un deployment canario desechable
+(`test-agent-canary`, `busybox:stable` con `exit 1` — CrashLoopBackOff
+garantizado): DRY_RUN detecta y "ejecuta" sin tocar el cluster, `--live`
+ejecuta de verdad (confirmado con `kubectl get events` y la anotación
+`restartedAt`), y una segunda corrida sobre el mismo recurso caído
+respeta el bloqueo (`notify_only`, sin reintento). Dos bugs reales se
+encontraron y corrigieron en esa prueba — ver el detalle en
+`docs/arquitectura/agente-monitoreo.md`.
 
-Con los secretos configurados, `--dry-run` corre el flujo completo
-(incluida la llamada real a `claude -p`, que sí tiene costo) pero
-sustituye la ejecución de `kubectl rollout restart`/`docker restart`
-por un mensaje `[DRY_RUN]` — no toca el cluster ni el contenedor de
-verdad. `DRY_RUN=1` es el valor por defecto en `lab-agent.env.example`;
-pasar `--live` (o `DRY_RUN=0` en el env) para el modo real.
-
-**No actives el timer de systemd (Paso 4) todavía.** Falta:
-Paso 3 (canal de notificación real), Paso 5 (prueba controlada con un
-escenario real de CrashLoopBackOff inducido, mostrándote los logs antes
-de habilitar el timer en continuo), y Paso 6 (documentar todo esto en
-docs-portal). Este script se puede correr manualmente para más pruebas
-de humo mientras tanto.
+**No actives el timer de systemd (Paso 4) todavía** — requiere tu
+confirmación explícita por separado, aunque la prueba end-to-end ya
+pasó.