respaldo: el progreso de rsync sólo con terminal — 2,6 MB de log ilegible

Sin TTY, --info=progress2 reescribe con \r y el progreso se acumula en
miles de copias de la misma línea. El respaldo corre DESATENDIDO, así que
ese log es la única forma de saber qué pasó; a 2,6 MB no se lee.

Mismo defecto y mismo arreglo que en worker-depositar.sh.

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

scripts/respaldo-storagebox.sh

@@ -95,7 +95,12 @@ SSH_CMD="ssh -4 -p $SB_PORT -i $KEY -o StrictHostKeyChecking=accept-new -o Serve
 # este script no, y ésa era toda la diferencia.
 # ⇒ Un error reintentable que se repite 40 veces no es un corte de red: es algo estructural. Vale la
 #   pena que el bucle distinga «se cayó una vez» de «falla siempre igual».
-RS="rsync -a --partial-dir=.rsync-partial --exclude /.dmerge --info=progress2 -z --compress-choice=zstd --compress-level=3"
+# `--info=progress2` SÓLO con terminal. Sin TTY reescribe la misma línea con `\r` y, como nadie
+# interpreta el retorno de carro, el «progreso» se acumula: una subida dejó un log de **2,6 MB**
+# donde lo único que importaba era la última línea. Con el respaldo corriendo desatendido (que es
+# como se corre), ese log es la única forma de saber qué pasó — y a 2,6 MB no se lee.
+PROG=""; [ -t 1 ] && PROG="--info=progress2"
+RS="rsync -a --partial-dir=.rsync-partial --exclude /.dmerge $PROG -z --compress-choice=zstd --compress-level=3"
 
 # ── REINTENTOS: EL ENLACE SE CAE, Y ESO NO ES EXCEPCIONAL ───────────────────────────────────────
 # Primera corrida real (2026-08-07): tras subir el cerebro y 2,3 G de store, murió con