docs: promote /web from develop (live restore progress + PBS encryption UX refresh)

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

web/messages/es/docs/backup-restore/destinations/pbs.json

@@ -52,9 +52,15 @@
     "heading": "Cifrado del lado del cliente",
     "intro": "El cifrado por keyfile del lado del cliente de PBS cifra los chunks en el host de origen antes de la subida. ProxMenux habilita esta funcionalidad con una restricción añadida: la passphrase de recuperación es obligatoria cuando se activa el cifrado. La passphrase no protege el keyfile local; protege la copia de escrow del keyfile que ProxMenux sube a PBS para recuperación ante desastre.",
     "keyfileTitle": "Keyfile",
-    "keyfileBody": "En el primer uso, <code>proxmox-backup-client key create --kdf none</code> genera el keyfile en <code>/usr/local/share/proxmenux/pbs-key.conf</code> (<code>chmod 600</code>). Las copias posteriores lo reutilizan tras un único diálogo de confirmación. Si la creación del keyfile falla, la copia se cancela y la salida de error de la herramienta se muestra en un diálogo.",
+    "keyfileBody": "El diálogo de cifrado sigue un flujo yes/no en dos pasos. El primer paso pregunta si se desea cifrar el backup: <em>No</em> continúa sin cifrado; <em>Yes</em> pasa al segundo paso. El segundo paso depende de si ya hay un keyfile instalado en <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Si lo hay, se reutiliza silenciosamente y el backup continúa. Si no lo hay, aparece un menú de dos opciones: <em>Generate a new keyfile</em>, que ejecuta <code>proxmox-backup-client key create --kdf none</code>, o <em>Import an existing keyfile</em>, que toma una ruta indicada por el operador, la valida con <code>proxmox-backup-client key info</code> y la instala en la ruta canónica. Ambas ramas se ejecutan solo tras confirmar la passphrase de recuperación — cancelar cualquier diálogo antes de ese punto deja el disco intacto.",
+    "modesTitle": "Keyfile por host o compartido",
+    "modesIntro": "Ambos modelos operativos están soportados y ninguno se impone — la decisión pertenece al usuario según cómo esté organizada su flota.",
+    "modesPerHostTitle": "Keyfile por host (por defecto)",
+    "modesPerHostBody": "Cada host genera su propio keyfile la primera vez que activa el cifrado PBS. El aislamiento es máximo: comprometer el keyfile de un host no expone las copias de ningún otro. Cada host tiene su propio blob de recuperación emparejado en PBS, restaurable con la passphrase de recuperación de ese host. Recomendado para flotas de producción y para entornos donde los hosts tienen propietarios o límites de compliance distintos.",
+    "modesSharedTitle": "Keyfile compartido (importar en cada host)",
+    "modesSharedBody": "Un keyfile maestro generado una vez e instalado en cada host mediante la opción <em>Importar</em>. La gestión es más simple: un único secreto que proteger, un único blob de recuperación sirve para todos los hosts, y cualquier host puede desencriptar los archives de cualquier otro (útil para consolidación, simulacros de restore cruzado o verificación centralizada de backups). El trade-off es que una filtración del keyfile compartido expone todos los hosts a la vez. Recomendado para homelabs y para flotas donde todos los hosts tienen el mismo propietario y límite de confianza.",
     "recoveryTitle": "Passphrase de recuperación y blob de escrow",
-    "recoveryBody": "Tras crear el keyfile, ProxMenux pregunta dos veces por una passphrase de recuperación (con validación de coincidencia) y ejecuta <code>openssl</code> para producir <code>pbs-key.recovery.enc</code> — el keyfile cifrado con la passphrase. Se escribe una copia en <code>/root/pbs-key.recovery-HOSTNAME-YYYYMMDD.enc</code> para almacenamiento offsite. Cancelar el diálogo de la passphrase borra el keyfile recién creado.",
+    "recoveryBody": "La passphrase de recuperación se solicita ANTES de escribir ningún keyfile en disco. ProxMenux la pide dos veces con validación de coincidencia; solo cuando el operador la confirma, se crea (o importa) el keyfile y <code>openssl</code> produce <code>pbs-key.recovery.enc</code> — el keyfile cifrado con la passphrase. Se escribe una copia en <code>/root/pbs-key.recovery-HOSTNAME-YYYYMMDD.enc</code> como respaldo offsite. Cancelar el diálogo de la passphrase deja el disco intacto — no se crea ningún keyfile y no hay nada que limpiar.",
     "blobUploadTitle": "Grupo emparejado en PBS",
     "blobUploadBody1": "Tras una copia PBS que usó el keyfile, el blob de escrow se sube como un segundo grupo de copia: <code>host/hostcfg-HOSTNAME-keyrecovery/BACKUP-TIME</code>. El prefijo compartido <code>hostcfg-HOSTNAME</code> coloca ambos grupos adyacentes en la interfaz de PBS; el sufijo <code>-keyrecovery</code> etiqueta la relación. La subida se ejecuta sin <code>--keyfile</code> (el blob ya está protegido con passphrase por openssl) y sólo cuando la copia actual usó el keyfile.",
     "blobUploadConstraintTitle": "Por qué dos grupos",

web/messages/es/docs/backup-restore/how-it-works.json

@@ -193,7 +193,7 @@
     ]
   },
   "whyItWorks": {
-    "heading": "Por qué la separación en tres bloques es la correcta",
+    "heading": "Por qué la separación en tres bloques es la usada",
     "body": "La separación no responde a una decisión de sistema de ficheros — responde a una decisión de <strong>ciclo de vida</strong>. El contenido del sistema de ficheros se mueve con <code>rsync</code>: rápido, transparente, atómico por fichero. El estado de configuración que la restauración tiene que interpretar antes de tocar el destino se mueve como <strong>JSON estructurado</strong>: legible de forma independiente, versionable mediante un esquema, diff-eable contra el estado propio del destino. El software que se tiene que reinstalar contra el entorno del destino se mueve como <strong>inventario</strong>: sólo nombres y versiones, dejando que el gestor de paquetes del destino y los instaladores propios de ProxMenux decidan los binarios reales. Cada bloque se optimiza para lo que tiene que hacer, y los tres combinan en una restauración que es atómica en la intención pero tolerante a fallos en la práctica: un manifiesto corrupto sigue dejando el rootfs restaurable, un paquete perdido sigue dejando los componentes instalables, un instalador que falla en una entrada no detiene la siguiente."
   }
 }

web/messages/es/docs/backup-restore/restoring.json

@@ -143,6 +143,41 @@
       }
     ]
   },
+  "liveProgress": {
+    "heading": "Progreso en vivo en la pestaña Backups del Monitor",
+    "body": "Tras el reboot, la pestaña Backups del Monitor de ProxMenux muestra una tarjeta de progreso en vivo que refleja el estado de <code>apply_cluster_postboot.service</code> a medida que avanza. La tarjeta lee <code>/var/lib/proxmenux/restore-state.json</code>, que el dispatcher actualiza en cada hito (aplicar configuración del cluster, reconstruir initramfs, actualizar bootloader, reinstalación por componente, verificación de arranque, finalización).",
+    "fields": [
+      {
+        "name": "Insignia de estado",
+        "detail": "Una de estas tres: <em>Restauración en curso</em>, <em>Restauración completa</em> o <em>Restauración fallida</em>. Mientras se ejecuta, la tarjeta consulta el fichero de estado cada 2 segundos; una vez terminada, cada 30 segundos."
+      },
+      {
+        "name": "Barra de progreso + contador de pasos",
+        "detail": "Muestra <code>N/M steps</code> con la etiqueta del paso actual. Durante la ejecución se calcula un <em>tiempo estimado</em> restante a partir de los pasos completados y el tiempo transcurrido."
+      },
+      {
+        "name": "Lista de componentes",
+        "detail": "Una fila por cada driver reinstalado (NVIDIA, Intel GPU tools, AMD tools, Coral TPU) con estado <code>installing</code> / <code>ok</code> / <code>failed</code> y un enlace al log por componente en <code>/var/log/proxmenux/component-*.log</code>."
+      },
+      {
+        "name": "Avisos de arranque",
+        "detail": "El dispatcher verifica si falta <code>/lib/modules/&lt;kernel&gt;</code>, si no hay ESP configurada y si hay un symlink <code>/vmlinuz</code> colgado. Cualquier aviso aparece aquí en un banner coloreado."
+      },
+      {
+        "name": "Delta de rollback",
+        "detail": "Lista VMs, LXCs y componentes que existen en el destino pero no estaban en el backup restaurado — las mismas entradas que aparecen en el diálogo de rollback destructivo pre-restore. Cada fila incluye el comando de limpieza manual."
+      },
+      {
+        "name": "Tail del log",
+        "detail": "Las últimas 600 líneas de <code>proxmenux-cluster-postboot-&lt;ts&gt;.log</code>, con un filtro <em>Issues only</em> que deja solo las líneas con <code>error</code>, <code>warning</code>, <code>failed</code>, <code>✗</code> o <code>traceback</code>."
+      }
+    ],
+    "dismissBody": "Cuando la restauración termina como <em>complete</em> o <em>failed</em>, el botón Dismiss colapsa la tarjeta. El fichero de estado se conserva y el botón History la reabre junto con cualquier restauración anterior (se archivan las últimas 20 en <code>/var/lib/proxmenux/restore-history/</code>).",
+    "imageAlt": "Pestaña Backups del Monitor de ProxMenux mostrando la tarjeta de progreso post-restauración tras una restauración completada, con la insignia verde \"Restore complete\", la barra de progreso llena, la duración del proceso y los recuadros de resumen (guests, bind-mount stubs, stale nodes cleaned, components).",
+    "imageCaption": "La tarjeta de la pestaña Backups tras finalizar el post-boot dispatcher — insignia de estado, barra al 100%, duración total y recuadros de resumen por componente.",
+    "detailsImageAlt": "Modal Details post-restauración abierto sobre la misma restauración completada, mostrando la barra final en 6/6 pasos, la sección Rollback delta indicando que no hay entradas nuevas y el tail del log completo con el conmutador Full / Issues only.",
+    "detailsImageCaption": "El modal Details de una restauración completada, con el log completo, el resultado de la verificación de arranque y el delta de rollback calculado contra el backup."
+  },
   "postbootExample": {
     "heading": "Cómo se ve el post-boot en la consola",
     "body": "En la consola física del host la ejecución exitosa del dispatcher termina con una línea <code>[ OK ] Finished proxmenux-apply-cluster-postboot.service</code>. Cuando esa línea aparece — normalmente acompañada de los <code>OK</code> del <code>multi-user.target</code> y del <code>graphical.target</code> — la restauración ha terminado por completo: componentes reinstalados, boot artifacts regenerados, cluster reconciliado.",