Describe the backup and restore behaviour as the scripts run it

- BORG_RSH, the Borg SSH wizard and attached jobs match the code
- Restore path classes name the right examples and when each path is written

web/messages/en/docs/backup-restore/destinations/borg.json

@@ -107,7 +107,7 @@
     "heading": "SSH authentication (client side)",
     "intro": "Remote Borg repositories are accessed over SSH. The connection runs from the ProxMenux host to a user account on the Borg server that runs <code>borg serve</code>. This user is typically named <code>borg</code>, NOT the admin/root user of the server — the borg-serve command line locks the connection to that specific repository path (see the key strategies below).",
     "strategiesTitle": "SSH key strategies",
-    "strategiesIntro": "When a remote target is added, ProxMenux asks for the SSH user, host and remote path, then offers four authentication choices. The additional generate-pct path is offered when password authentication is refused. The modes are described below:",
+    "strategiesIntro": "When a remote target is added, ProxMenux asks for the SSH user, host, port and remote path, then offers four authentication choices. The additional generate-pct path is offered when password authentication is refused. The modes are described below:",
     "strategyRows": [
       {
         "mode": "generate-auto",
@@ -166,7 +166,7 @@
       {
         "var": "BORG_RSH",
         "value": "ssh -i SSH_KEY_PATH -o IdentitiesOnly=yes -o StrictHostKeyChecking=accept-new [-p PORT]",
-        "purpose": "The remote-shell command Borg uses for SSH repositories. A selected key adds the identity options; a non-default port adds -p PORT. With no custom key and the default port, the variable is unset so Borg uses the host’s default SSH configuration."
+        "purpose": "The remote-shell command Borg uses for SSH repositories. A selected key adds the identity options. When a target is first added with a non-default port, ProxMenux also appends -p PORT; saved targets, scheduled jobs and the Monitor rely on the port in the ssh:// URL instead. Without a custom key, and for a newly added target with the default port, the variable is unset so Borg uses the host’s default SSH configuration."
       },
       {
         "var": "BORG_PASSPHRASE",

web/messages/en/docs/backup-restore/glossary.json

@@ -156,7 +156,7 @@
         {
           "id": "modo-adjunto",
           "term": "Attach mode",
-          "def": "Job without its own timer. A PVE <code>vzdump</code> job-end hook triggers it after guest backups when the destination storage matches. The selected parent supplies storage and initial retention, but the hook matches storage rather than parent job ID; another task using that storage may also trigger it. Supported for Local and PBS only."
+          "def": "Job without its own timer. A PVE <code>vzdump</code> job-end hook triggers it after guest backups when the destination storage matches. The selected parent supplies the storage and the retention, which is re-read from the parent job on every run, but the hook matches storage rather than parent job ID; another task using that storage may also trigger it. Supported for Local and PBS only."
         },
         {
           "id": "timer-systemd",

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

@@ -81,11 +81,11 @@
       },
       {
         "class": "reboot",
-        "detail": "Paths deferred to the <strong>next boot</strong>, rather than applied <strong>immediately</strong> by this restore flow. They affect boot-time configuration: bootloader generation reads <code>/etc/default/grub</code>, filesystem mounting uses <code>/etc/fstab</code>, and module loading uses <code>/etc/modules</code>. The pending files are applied after reboot and the required boot artifacts are then regenerated. Examples: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/initramfs-tools</code>."
+        "detail": "Paths deferred to the <strong>next boot</strong>, rather than applied <strong>immediately</strong> by this restore flow. They affect boot-time configuration: bootloader generation reads <code>/etc/default/grub</code>, filesystem mounting uses <code>/etc/fstab</code>, and module loading uses <code>/etc/modules</code>. The pending files are applied after reboot and the required boot artifacts are then regenerated. Examples: <code>/etc/default/grub</code>, <code>/etc/kernel</code>, <code>/etc/modules</code>, <code>/etc/fstab</code>, <code>/etc/zfs</code>, <code>/etc/modprobe.d</code>."
       },
       {
         "class": "dangerous",
-        "detail": "Paths that are <strong>NOT applied on the running system</strong> — a live write could corrupt state or drop the active connection. These are staged in the pending set and written by the post-boot dispatcher after the reboot, when the cluster is up but the system is not yet fully in use. Examples: <code>/etc/pve</code> (pmxcfs is a live FUSE mount holding active cluster configuration), <code>/var/lib/pve-cluster</code> (live cluster data), <code>/etc/network</code> (could reconfigure the very interface the user is connected on over SSH and drop the session)."
+        "detail": "Paths that are <strong>NOT applied on the running system</strong> — a live write could corrupt state or drop the active connection. These are staged in the pending set: <code>/etc/network</code> is written early in the next boot, before networking starts, and <code>/etc/pve</code> is written by the post-boot dispatcher once the cluster filesystem is up. Examples: <code>/etc/pve</code> (pmxcfs is a live FUSE mount holding active cluster configuration), <code>/var/lib/pve-cluster</code> (live cluster data, kept in the recovery directory for manual recovery only), <code>/etc/network</code> (could reconfigure the very interface the user is connected on over SSH and drop the session)."
       }
     ]
   },