roswell: explicar por qué 8Gi ya no es una cifra perseguida

El límite subió 4→6→8Gi persiguiendo episodios largos porque el pico de
whisper escalaba con la duración. Con el troceado en ventanas (roswell-corpus
c869b61) el pico dejó de depender del episodio, así que 8Gi pasa de ser el
siguiente escalón a tener margen de sobra. Se deja escrito para que nadie lo
suba por inercia sin mirar antes si el troceado sigue vivo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

roswell/deployment.yaml

@@ -99,9 +99,18 @@ spec:
               memory: "512Mi"
               cpu: "500m"
             limits:
-              # Whisper large-v3 INT8 en CPU: el pico real supera los 4Gi que
+              # Whisper large-v3 INT8 en CPU. Este límite subió tres veces
-              # estimaba el PLAN §10 (OOMKilled verificado el 2026-07-13) y los
+              # persiguiendo episodios cada vez más largos (4Gi del PLAN §10 →
-              # 6Gi con episodios largos (80 min OOMKilled el 2026-07-24).
+              # 6Gi tras el OOM del 2026-07-13 → 8Gi tras el del 2026-07-24,
+              # un episodio de 80 min), porque faster-whisper procesaba el
+              # fichero ENTERO de golpe al arrancar y el pico escalaba con la
+              # duración. Desde `_plan_windows` (roswell-corpus c869b61,
+              # 2026-07-26) el audio largo se transcribe en ventanas de ~20 min
+              # y el pico ya no depende de lo que dure el episodio: el mismo
+              # episodio de 113 min que tocaba el techo tres veces
+              # (memory.events max=3) pasó a max=0, con ~3,9Gi de anon.
+              # NO volver a subirlo sin comprobar antes que el troceado sigue
+              # activo: la línea "Audio de N min: X ventanas" en el log.
               # Sin límite de CPU: la transcripción usa los cores libres.
               memory: "8Gi"
       # Nodo grande (16 cores / 29Gi): transcribe a ~1x tiempo real y comparte