Describe the disk manager behaviour as the scripts run it

- Wipe all trims the whole disk when discard is supported and is not a secure erase
- Declining the privileged conversion changes nothing, and accepting backs up the configuration first
- The by-id path is used when it exists, with /dev/sdX as fallback
- Full report opens in a scrollable dialog; SAS progress comes from the self-test log

web/messages/en/docs/disk-manager/format-disk.json

@@ -46,7 +46,7 @@
         "mode": "1. Wipe all",
         "part": "Destroyed",
         "data": "Signatures wiped",
-        "useCase": "Remove partitioning and metadata to prepare a new layout. This does not overwrite all user data."
+        "useCase": "Removes the partition table and the filesystem and RAID metadata, zeroes the first and last 16 MiB and, on drives that support discard, trims the whole disk. The rest of the data is not overwritten and may still be recoverable on HDDs; this is not a secure erase."
       },
       {
         "mode": "2. Remove FS labels",

web/messages/en/docs/disk-manager/import-disk-lxc.json

@@ -83,7 +83,7 @@
   "troubleshoot": {
     "heading": "Troubleshooting",
     "unprivTitle": "\"Cannot continue with an unprivileged container\"",
-    "unprivBody": "You declined the conversion. The flag in <code>/etc/pve/lxc/&lt;CTID&gt;.conf</code> changes from <code>unprivileged: 1</code> to <code>unprivileged: 0</code>, but that alone does not convert existing UID/GID ownership. Back up and handle the ownership mapping before accepting an in-place conversion; alternatively restore or rebuild the container as privileged.",
+    "unprivBody": "You declined the conversion, so the script stopped without changing anything. To continue, run it again and accept: the script stops the container, backs up its configuration to <code>/etc/pve/lxc/&lt;CTID&gt;.conf.bak</code> and replaces <code>unprivileged: 1</code> with <code>unprivileged: 0</code>. That flag change alone does not convert the UID/GID ownership of existing files, so back up the container and fix the ownership first; alternatively, restore or rebuild the container as privileged.",
     "permsTitle": "Permissions inside the container are wrong",
     "permsBody": "Existing file ownership is retained when a partition is mounted into a privileged container; a newly formatted filesystem is often owned by <code>root:root</code>. If the service runs as another user (e.g. <code>www-data</code> for Nextcloud), inspect its UID/GID and adjust the required files with <code>chown</code>/<code>chmod</code>. Changes also affect the underlying disk."
   },

web/messages/en/docs/disk-manager/import-disk-vm.json

@@ -12,7 +12,7 @@
   },
   "intro": {
     "title": "What this does",
-    "body": "This attaches a raw physical disk as the backing device for a virtual disk interface. The guest does not automatically receive native SMART data or the physical controller’s features; use controller PCI passthrough when those are required. The disk is attached through <code>/dev/disk/by-id/…</code>, not <code>/dev/sdX</code>, so a changed device enumeration order at boot does not break the assignment."
+    "body": "This attaches a raw physical disk as the backing device for a virtual disk interface. The guest does not automatically receive native SMART data or the physical controller’s features; use controller PCI passthrough when those are required. The disk is attached through its <code>/dev/disk/by-id/…</code> path when one exists, so a changed device enumeration order at boot does not break the assignment; otherwise <code>/dev/sdX</code> is used."
   },
   "howRuns": {
     "heading": "How the script runs",

web/messages/en/docs/disk-manager/smart-disk-test.json

@@ -89,7 +89,7 @@
       },
       {
         "title": "Review results",
-        "bodyRich": "Status and reports are shown in the terminal; JSON export is performed for supported actions as described above, not for Full report. For long tests, return later and run <strong>Check test progress</strong> on the same disk to see the outcome.",
+        "bodyRich": "Status, test and progress output is shown in the terminal; <strong>Full report</strong> opens in a scrollable dialog. JSON is exported for the actions described above, not for Full report. For long tests, return later and run <strong>Check test progress</strong> on the same disk to see the outcome.",
         "img": "/disk/smart/quick-status.png",
         "alt": "Quick health status output",
         "caption": "Quick health status output (SATA — smartctl -H + -A)"
@@ -106,7 +106,7 @@
     "noSmartTitle": "\"Could not read SMART data from /dev/sdX\"",
     "noSmartBody": "The disk is probably behind a RAID / SAS controller that does not pass SMART through. With megaraid-based cards, try <code>smartctl -d megaraid,N /dev/sdX</code>. For HBAs in IT mode the direct invocation works.",
     "longTitle": "Long test never completes",
-    "longBody": "The drive runs the test in firmware, and heavy I/O can delay completion. Try an idle period such as overnight. For SATA/SAS, <code>smartctl -c</code> shows the remaining percentage; inspect the self-test log for completion status and any failing LBA. A reported read failure needs investigation; slow progress alone does not prove a bad sector."
+    "longBody": "The drive runs the test in firmware, and heavy I/O can delay completion. Try an idle period such as overnight. For SATA, <code>smartctl -c</code> shows the remaining percentage, and for SAS, <code>smartctl -l selftest</code>; inspect the self-test log for completion status and any failing LBA. A reported read failure needs investigation; slow progress alone does not prove a bad sector."
   },
   "related": {
     "heading": "Related",