n8n: no guardar el payload de las ejecuciones exitosas

La poda por edad ya estaba activa de serie (n8n 2.15.1, prune=true, 336 h):
los IDs de ejecucion empiezan en 22.634 con 7.052 filas, o sea que ya habia
borrado ~22.600 el solo. El tar diario crecia 0,4 MB/dia y estaba llegando a
meseta, asi que no habia desbocamiento: la premisa era falsa.

El problema real era la composicion. De 322 MB de execution_data, 246 MB
(76%) eran las 3.436 ejecuciones EXITOSAS de 'Real Madrid RSS -> Twitter',
que corre cada 5 min y guarda 73 KB por vuelta. Sus errores -lo unico que
sirve para depurar- ocupaban 2 MB.

Y no es un problema de disco (21%, 699 GB libres) sino de backup: n8n esta
en CROWN, asi que ese .tar.gz de 101 MB viajaba entero a MEGA cada dia y a
B2 en las dos ultimas copias. Es justo el gasto que revento la cuota el
2026-07-25.

Nada depende de ese historico: el monitor de reversion solo lee
workflow_entity, el panel de Grafana mira replicas del deployment y
'Resumen Diario' saca metricas de k8s por un nodo Code.

n8n/deployment-n8n.yaml

@@ -80,6 +80,17 @@ spec:
               value: sqlite
             - name: DB_SQLITE_DATABASE
               value: /home/node/.n8n/database.sqlite
+            # No guardar el payload de las ejecuciones que salen BIEN (2026-07-30).
+            # La poda por edad ya venía activa de serie (336 h), así que la BD no
+            # se desbocaba; el problema era otro: de los 322 MB de execution_data,
+            # 246 MB eran las 3.436 tiradas VERDES de "Real Madrid RSS → Twitter",
+            # que corre cada 5 min y guarda 73 KB por vuelta. Los fallos, que son
+            # lo que se depura, ocupaban 2 MB. Y /data/n8n va entero en la lista
+            # CROWN del backup: eso viajaba a MEGA a diario y a B2 en las dos
+            # últimas copias — justo lo que reventó la cuota el 2026-07-25.
+            # Los errores se siguen guardando enteros (SAVE_ON_ERROR=all, defecto).
+            - name: EXECUTIONS_DATA_SAVE_ON_SUCCESS
+              value: none
           resources:
             requests:
               cpu: 100m