superguardado: reboot resiliente - comando reboot/servicios en bot + tunel autossh como servicio systemd + lecciones 32-35

docs/lecciones_aprendidas_vigilancia.md

@@ -86,3 +86,14 @@
 
 31. **stdout de tv-api en systemd está buffered**: Los `print()` de tv_api no salen en `journalctl` hasta flush. Para ver el resultado del casting, usar un proceso limpio o logear a archivo.
 
+### Reboot resiliente (02 agosto noche)
+
+32. **El túnel autossh debe ser servicio systemd, no proceso manual**: El autossh corría como proceso manual y NO se reiniciaba al reboot → la Pi quedaba inaccesible desde fuera. Convertido a `/etc/systemd/system/autossh-tunel.service` (enabled). Comando real del túnel: `autossh -M 0 -N -o ServerAliveInterval=30 ... -R 2222:localhost:22 -R 8600:localhost:8600 root@VPS`.
+
+33. **Sintaxis de opciones de autossh**: Debe ser `-o ServerAliveInterval=30` (con `=`). Con espacio (`-o ServerAliveInterval 30`) ssh falla con `no argument after keyword serveraliveinterval` y entra en bucle de restart. Cuando hay 2 túneles compitiendo da `remote port forwarding failed for listen port 2222` — limpiar TODOS los procesos (`pkill -9 -f autossh` y `pkill -9 -f "ssh.*-R"`) antes de relanzar el servicio.
+
+34. **Comandos Telegram para operar la Pi**: Añadidos `/servicios` (estado pi-bot, tv-api, autossh-tunel + túnel) y `/reboot` → `/confirmar-reboot` (reinicia la Pi con doble confirmación desde Telegram). Probado con reboot real: tras 1 min la Pi vuelve y todos los servicios + túnel operan solos.
+
+35. **Tras un reboot real se valida todo**: pi-bot, tv-api y autossh-tunel están `enabled` (arrancan solos). El bot conserva el offset en `bot.offset` así que no reprocesa nada. La TV, el túnel y el acceso remoto quedan operativos sin intervención manual.
+
+