docs(pbs): promote /web from develop — keyfile UX refresh

- Explicit yes/no escrow choice reinforced ("nothing gets uploaded to PBS
  until the operator answers Yes") in intro + recoveryTitle + recoveryBody
- Wrong-key detection: recoverBody extended to describe the structured
  amber panel that Monitor shows on View contents / Download / Restore
  when the installed keyfile doesn't match the backup's manifest, with
  the required fingerprint rendered prominently
- New encryption.monitorManagement section: describes the Download /
  Upload / Delete inline actions in each PBS destination row, plus the
  Yes/No + passphrase + contextual Apply escrow toggle
- ES: "operador" → "usuario" throughout (glossary rule)
- page.tsx: renders the new subsection and passes {code, em, strong} to
  the extended recoveryBody

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

@@ -50,28 +50,30 @@
   },
   "encryption": {
     "heading": "Cifrado del lado del cliente",
-    "glossaryHint": "En esta sección aparecen los términos <em>clave</em>, <em>passphrase</em> y <em>sobre de recuperación</em>. Si en algún momento cuesta seguir cuál es cuál, el <glosarioLink>glosario</glosarioLink> resume las diferencias en una frase por término.",
-    "intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. Sin esa clave, las copias no pueden descifrarse. ProxMenux añade una salvaguarda: cuando se activa el cifrado obliga a definir una <strong>passphrase de recuperación</strong>. Esa passphrase no protege la clave local (que ya vive en el host), sino una copia cifrada de la clave que ProxMenux sube al propio PBS, para poder recuperarla si el host se pierde o se reinstala.",
-    "keyfileTitle": "La clave de cifrado (keyfile)",
-    "keyfileBody": "El diálogo pregunta primero si se quiere cifrar la copia. Si se responde <em>No</em>, la copia continúa sin cifrado. Si se responde <em>Sí</em>, ProxMenux comprueba si el host ya tiene una clave instalada: en ese caso la reutiliza sin más preguntas; si no la tiene, ofrece dos opciones. <em>Generar una clave nueva</em> crea una clave sin contraseña, para que las copias programadas puedan ejecutarse automáticamente sin diálogos. <em>Importar una clave existente</em> permite indicar la ruta de una clave ya generada —por ejemplo la clave común de una flota de hosts—; en ese caso el diálogo pide también la contraseña de esa clave y la guarda cifrada en el host para reutilizarla en cada copia. Cualquiera de las dos opciones se ejecuta solo después de confirmar la passphrase de recuperación; cancelar el diálogo antes de ese punto no deja nada en disco.",
-    "modesTitle": "Keyfile por host o compartido",
+    "glossaryHint": "En esta sección aparecen los términos <em>clave</em>, <em>passphrase</em> y <em>sobre de recuperación</em>. El <glosarioLink>glosario</glosarioLink> resume las diferencias en una frase por término.",
+    "intro": "PBS puede cifrar las copias con una clave que reside únicamente en el host de origen: los datos se cifran en el propio host antes de subirse, y en PBS solo se guardan cifrados. En ProxMenux el cifrado es opcional; al activarlo, subir también a PBS una copia de la clave envuelta con una passphrase (el sobre de recuperación) es una decisión sí/no explícita que toma el usuario durante la configuración inicial (y que puede revisar más tarde desde el Monitor). La clave siempre vive en una única ruta canónica del host — <code>/usr/local/share/proxmenux/pbs-key.conf</code> — y se reutiliza en silencio en todas las copias cifradas siguientes.",
+    "keyfileTitle": "Configuración inicial de la clave",
+    "keyfileBody": "El diálogo aparece en la primera copia cifrada del host. Primero pregunta si se quiere cifrar la copia: <em>No</em> continúa sin cifrado; <em>Sí</em> pasa al segundo paso. El segundo paso depende de si ya hay una clave instalada en <code>/usr/local/share/proxmenux/pbs-key.conf</code>. Si la hay, se reutiliza en silencio y la copia continúa — las copias posteriores no vuelven a preguntar. Si no la hay, aparece un menú con dos opciones. <em>Generar una clave nueva</em> ejecuta <code>proxmox-backup-client key create --kdf none</code>. <em>Usar una clave existente</em> autodetecta una clave gestionada por PVE: si el repositorio PBS seleccionado está registrado en Proxmox con encryption-key en <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, ese fichero se copia a la ruta canónica de ProxMenux en silencio y el flujo continúa. Cuando ninguna clave PVE coincide con el repositorio, aparece un input pidiendo la ruta absoluta donde el usuario ha colocado la clave en este host. En cualquier caso, el fichero acaba en la ruta canónica con <code>chmod 600</code>.",
+    "modesTitle": "Clave por host o compartida",
     "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 propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a las copias de ningún otro. Cada host guarda además su propio sobre de recuperación en PBS, que se abre con la passphrase de recuperación de ese host. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
+    "modesPerHostTitle": "Clave por host (por defecto)",
+    "modesPerHostBody": "Cada host genera su propia clave la primera vez que se activa el cifrado. Es el modo con mayor aislamiento: si la clave de un host se ve comprometida, no afecta a las copias de ningún otro. Recomendado para entornos de producción y para escenarios donde cada host tiene su propio responsable o requisitos distintos.",
     "modesSharedTitle": "Clave compartida (importar la misma en cada host)",
-    "modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Importar</em>. La gestión es más sencilla: hay un solo secreto que proteger, un solo sobre de recuperación válido para todos los hosts, y cualquier host puede leer las copias de cualquier otro (útil para verificar copias desde una máquina distinta o para ejercicios de restauración cruzada). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
-    "recoveryTitle": "Passphrase de recuperación y sobre cifrado",
-    "recoveryBody": "La passphrase de recuperación se pide ANTES de generar o importar ninguna clave. ProxMenux la solicita dos veces y comprueba que coincidan; solo entonces crea la clave y produce el sobre de recuperación, que consiste en la propia clave cifrada con esa passphrase. Se guarda además una copia local del sobre en <code>/root/</code>, con el nombre del host y la fecha, pensada como respaldo externo (para llevarla a otro medio). Si se cancela el diálogo de la passphrase, no se crea nada: el host queda exactamente como estaba.",
+    "modesSharedBody": "Se genera una única clave y se importa en todos los hosts mediante la opción <em>Usar una clave existente</em>. La gestión es más sencilla: hay un solo secreto que proteger, y cualquier host puede leer las copias de cualquier otro (útil para verificación centralizada, ejercicios de restauración cruzada o consolidación). A cambio, si la clave compartida se filtra queda expuesto todo el conjunto de hosts a la vez. Recomendado para laboratorios personales y entornos donde todos los hosts pertenecen al mismo responsable y comparten el mismo nivel de confianza.",
+    "recoveryTitle": "¿Subir la clave a PBS? — el usuario decide",
+    "recoveryBody": "Justo después de elegir la clave, ProxMenux hace una única pregunta explícita — <em>Upload key to PBS?</em> — con dos respuestas. <strong>No se sube nada a PBS hasta que el usuario responde Sí.</strong> La opción por defecto es <em>No, keep local only</em>: la clave se queda únicamente en la ruta canónica local, ProxMenux no toca PBS con ningún artefacto de recuperación, y el usuario gestiona su propia copia offsite (el botón <em>Download keyfile</em> en la fila de destino PBS del Monitor la genera bajo demanda). Al elegir <em>Yes, upload</em>, ProxMenux pide una passphrase de recuperación —dos veces, comprobando que coincidan— y envuelve la clave con esa passphrase usando AES-256-CBC y PBKDF2 (600 000 iteraciones, sal aleatoria) para producir <code>pbs-key.recovery.enc</code>. Todas las copias cifradas siguientes suben ese sobre a PBS como grupo emparejado. Ni la passphrase ni una copia en claro de la clave salen nunca del host. La elección se puede cambiar más adelante desde el Monitor en cualquier momento — el interruptor de escrow inline en la fila del destino PBS conmuta Sí/No y se aplica en el acto (Start uploading, Stop uploading o Update passphrase, según el estado actual).",
     "blobUploadTitle": "Grupo emparejado en PBS",
-    "blobUploadBody1": "Tras una copia cifrada, ProxMenux sube el sobre de recuperación a PBS como un segundo grupo de copia, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Así aparecen los dos juntos en el listado del datastore, uno con las copias del host y otro con los sobres de recuperación. <strong>El sobre nunca sale del host en claro</strong>: antes de subirse, ProxMenux lo transforma en el propio host en un fichero cifrado con AES-256-CBC, usando una clave derivada de la passphrase de recuperación mediante PBKDF2 con 600 000 iteraciones y sal aleatoria (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recibe únicamente el sobre ya cifrado, y solo se sube cuando la copia principal ha ido cifrada.",
+    "blobUploadBody1": "Cuando el modo elegido es <em>Yes, upload</em>, ProxMenux sube el sobre de recuperación a PBS después de cada copia cifrada como un segundo grupo emparejado, con el mismo nombre que el del host pero terminado en <code>-keyrecovery</code>. Los dos grupos aparecen juntos en el listado del datastore, uno con las copias del host y otro con los sobres. <strong>El sobre nunca sale del host en claro</strong>: el cifrado ocurre en el propio host con AES-256-CBC y PBKDF2 antes de que se envíe un solo byte (<code>openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt</code>). PBS recibe únicamente el sobre ya cifrado.",
     "envelopeSecurityTitle": "¿No es un riesgo subir el archivo keyrecovery a PBS?",
-    "envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el operador dispone de ambas.",
+    "envelopeSecurityBody": "El keyrecovery viaja y se almacena cifrado en todo momento. La passphrase de recuperación nunca abandona el host: el cifrado ocurre localmente antes de la subida y PBS solo recibe el resultado ya cifrado. Aunque un administrador de PBS —o cualquiera con acceso al datastore— descargue el keyrecovery, sin la passphrase de recuperación no puede leer la clave que contiene: son solo bytes cifrados. Para reconstruir la clave hacen falta las dos cosas al mismo tiempo, el keyrecovery y la passphrase, y solo el usuario dispone de ambas.",
     "blobUploadConstraintTitle": "Por qué dos grupos y no uno solo cifrado",
     "blobUploadConstraintBody": "Una misma subida de <code>proxmox-backup-client backup</code> cifra todos sus archivos con la misma clave, o no cifra ninguno — no hay opción intermedia. La copia del host tiene que ir cifrada con la clave del host; el sobre de recuperación no puede ir en esa misma subida, porque quedaría cifrado con la clave que precisamente contiene: en un equipo recién reinstalado no habría manera de abrirlo (haría falta la clave para descifrar la clave). Por eso se hacen dos subidas independientes y aparecen como dos grupos separados: la copia del host va cifrada por PBS con la clave, y el sobre de recuperación va cifrado por ProxMenux con la passphrase antes de subirse. Son dos capas de cifrado distintas que protegen dos activos distintos.",
     "blobUploadImageAlt": "Interfaz de PBS mostrando los grupos hostcfg-HOSTNAME y hostcfg-HOSTNAME-keyrecovery adyacentes en el listado del datastore.",
-    "blobUploadImageCaption": "Interfaz de PBS — los grupos de copia emparejados. El grupo principal contiene las copias del host; el grupo -keyrecovery contiene el blob de escrow.",
+    "blobUploadImageCaption": "Interfaz de PBS — los grupos de copia emparejados. El grupo principal contiene las copias del host; el grupo -keyrecovery contiene la clave envuelta con la passphrase.",
     "recoverTitle": "Recuperación en un equipo recién instalado",
-    "recoverBody": "Si se intenta restaurar en un equipo que no tiene todavía la clave de cifrado —por ejemplo tras reinstalar el host desde cero—, ProxMenux consulta los grupos de recuperación del PBS configurado, descarga el sobre más reciente y pide la passphrase de recuperación. Al confirmarla, la clave queda instalada en el host y la copia cifrada ya puede restaurarse con normalidad. Sin la clave y sin la passphrase, la copia cifrada no puede recuperarse."
+    "recoverBody": "Cuando falta la clave en la ruta canónica —tras reinstalar el host desde cero o después de eliminarla explícitamente— el flujo de restauración prueba tres fuentes en orden y se queda con la primera que produce una clave usable. Primero, si el repositorio PBS seleccionado tiene una clave gestionada por PVE en <code>/etc/pve/priv/storage/&lt;NAME&gt;.enc</code>, ese fichero se copia a la ruta canónica en silencio. Segundo, si hay un grupo <code>-keyrecovery</code> disponible en PBS, se descarga el snapshot más reciente y se pide al usuario la passphrase de recuperación para descifrarlo. Tercero, si ninguna de las dos vías anteriores funciona o el usuario las declina, aparece un input pidiendo la ruta absoluta donde vive la clave en este host, y el fichero se copia a la ruta canónica. El Monitor expone el mismo flujo de importación de forma inline en el modal de detalle de la copia — aparece un panel ámbar en la parte superior cuando Restaurar, Descargar o Ver contenido necesitarían una clave que no está instalada. Cuando la clave sí está instalada pero no coincide con la que cifró la copia, PBS devuelve un error <code>wrong key — manifest's key XX does not match provided key YY</code>; las mismas tres acciones muestran un panel ámbar estructurado con el fingerprint del manifest destacado en primer plano, para que el usuario pueda identificar qué clave importar para abrir esa copia concreta.",
+    "monitorManagementTitle": "Gestionar la clave desde el Monitor",
+    "monitorManagementBody": "El Monitor expone los controles de la clave de forma inline en cada fila de destino PBS de la página de configuración de copias. La fila muestra tres acciones: <em>Descargar</em> exporta la clave actual al navegador del usuario, <em>Subir</em> reemplaza la clave instalada por una que aporta el usuario (el fichero anterior solo se sobrescribe cuando el nuevo llega correctamente a la ruta canónica), y <em>Eliminar</em> retira la clave del host. El interruptor del sobre de recuperación es un único control inline junto a esas acciones: un radio Sí/No para <em>Upload key to PBS?</em>, un campo de passphrase cuando se selecciona Sí, y un botón Apply contextual que dice <em>Start uploading</em>, <em>Stop uploading</em> o <em>Update passphrase</em> según el estado actual. Todas las acciones pasan por los mismos endpoints Flask que usa el TUI del shell, así que el efecto en disco y en PBS es idéntico independientemente de qué superficie elija el usuario."
   },
   "restoreAccess": {
     "heading": "Recuperación del lado de la restauración",