docs(docs-portal): reflejar fixes de MTU, gitea-runner y cosign digest/rekor

Nuevo playbook del blackhole MTU cross-node (diagnostico + fix + validacion).
Actualiza el playbook de contencion de recursos Gitea/runner de 'pendiente'
a 'aplicado'. Actualiza cosign.md: firma por digest ya implementada, Rekor
como decision tomada (no TODO). Corrige 2 links que quedaron rotos al
renombrar la seccion de limitaciones (validado con mkdocs build --strict).

Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_011FqYP3Wf1W63Qmh7qgXAAT

workloads/docs-portal/docs/playbooks/incidente-contencion-recursos-gitea-runner-2026-08.md

@@ -97,37 +97,32 @@ distintos: el `docker-compose.yml` de `gitea` y el script que crea
     job pesado, sin ningún límite de recursos, puede acaparar
     suficiente CPU/memoria como para dejar sin aire al resto del host.
 
-## Fix propuesto (documentado, aplicación manual pendiente)
+## Fix aplicado (2026-08-16)
 
-1. **`scripts/deploy-lab.sh`** (rama `fix/gitea-runner-resource-limits`,
-   pendiente de mergear): agrega `--cpu-shares 512 --memory 8g
-   --memory-swap 10g` a la creación de `gitea-runner`. Solo afecta a la
-   próxima vez que se cree el contenedor (la función es idempotente),
-   no al que ya está corriendo.
-2. **Fix inmediato en caliente** (sin recrear contenedores), a aplicar
-   manualmente por fuera de este repo:
-
-    ```bash
-    docker update --cpu-shares 1024 gitea
-    docker update --cpu-shares 512 --memory 8g --memory-swap 10g gitea-runner
-    ```
-
-3. **`docker-compose.yml` de Gitea** (fuera de este repo, acceso
-   root-only): subir `cpu_shares` de `gitea` de 90 a 1024 — pendiente
-   de aplicar manualmente, no se implementó todavía.
-4. **Mover `gitea-runner` a k3d** como job/pod separado: evaluado como
-   posible mejora de fondo (aislamiento real vía Kubernetes en vez de
-   límites de Docker sueltos), pero queda **solo como recomendación
-   documentada** — no implementado en esta vuelta.
+1. **`scripts/deploy-lab.sh`** (mergeado a `main`): agrega
+   `--cpu-shares 512 --memory 8g --memory-swap 10g` a la creación de
+   `gitea-runner`. Solo afecta a la próxima vez que se recree el
+   contenedor (la función es idempotente) — el runner queda con menos
+   prioridad relativa que Gitea a propósito.
+2. **`docker-compose.yml` de Gitea** (fuera de este repo, en el host
+   ZimaOS — `/DATA/.casaos/apps/gitea/docker-compose.yml`, acceso
+   root-only): `cpu_shares` de `gitea` subido de 90 a **1024**
+   (el default de Docker), aplicado en caliente con
+   `docker compose up -d` y validado con `docker inspect`.
+3. **Mover `gitea-runner` a k3d** como job/pod separado: sigue quedando
+   **solo como recomendación documentada**, no implementado — la
+   contención real ya se resolvió con los límites de arriba, así que
+   esto pasa a ser una mejora de aislamiento a futuro, no una urgencia.
 
 ## Validación
 
-Con `gitea` y `gitea-runner` estables (sin reinicios) después del
-incidente, se reintentó el mismo pipeline y corrió de punta a punta
-sin interrupciones — pero eso confirma que el host se estabilizó
-después del pico de carga, **no** que el fix de límites de recursos ya
-esté aplicado (sigue pendiente, ver arriba). La correlación completa
-carga-pesada → reinicio ya se había visto antes, en dos fechas
-distintas (2026-07-30 y 2026-08-11) además de esta — no es un evento
-aislado, es un patrón recurrente que ahora tiene una causa raíz
-concreta y una propuesta de fix.
+Con el fix aplicado: `docker inspect gitea --format
+'{{.HostConfig.CpuShares}}'` confirma `1024`, el contenedor se recreó
+limpio (`Started`, sin errores) y siguió sirviendo tráfico normal
+(`200 OK` en `http://127.0.0.1:3002/` inmediatamente después). La
+correlación completa carga-pesada → reinicio se había visto en tres
+fechas distintas (2026-07-30, 2026-08-11 y el propio 2026-08-15 de este
+incidente) antes de este fix — no era un evento aislado. Queda por
+confirmar con el próximo pipeline pesado real que la contención no
+vuelva a aparecer, pero la causa raíz (pesos de CPU desbalanceados y sin
+techo de memoria en el runner) ya no está presente.