docs(admin): address review feedback on external storage change detection

- Reword "Once per direct access" and "Never" bullets for accuracy
- Drop overly long trailing clause from etag propagation paragraph
- Replace files:scan --all with files_external:scan <mount_id>
- Remove --all recommendation and AIO note (resource concerns)
- Broaden rename limitation: applies to both scan modes, not just cron

Signed-off-by: skjnldsv <skjnldsv@protonmail.com>

Author: skjnldsv

admin_manual/configuration_files/external_storage_configuration_gui.rst

@@ -182,10 +182,10 @@ The **Filesystem check frequency** mount option (see
 ``PROPFIND`` request reaches the Nextcloud server for a path inside the external
 storage:
 
-* **Once per direct access** — the server rescans that directory level on the first
-  ``PROPFIND`` per PHP request, then updates the filecache for what it finds there.
-* **Never** — the server skips the rescan entirely and always returns the cached
-  state.
+* **Once per direct access** — during ``PROPFIND`` requests made to a given directory,
+  Nextcloud rescans that directory level then updates the filecache with what it finds there.
+* **Never** — the server never rescans the external storage during ``PROPFIND`` requests
+  and always returns the content stored in its internal index.
 
 This option is *only* about the server's behaviour during a ``PROPFIND``. It does
 not trigger any background polling and does not change how desktop clients or
@@ -205,9 +205,7 @@ folder up to the root must also change, giving the client a trail to follow down
 to the changed file.
 
 When a change is made outside Nextcloud, no etag is updated. The client sees no
-trail from the root and never follows it down to the changed file — even if the
-file itself is eventually rescanned at a deeper level, the propagation up to the
-root must still happen before the client can discover it.
+trail from the root and never follows it down to the changed file.
 
 How to make external changes reliably detectable
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -231,47 +229,30 @@ requirements and how to reduce sync delay.
 **B) All other storages — periodic rescan via cron**
 
 For storage types that do not support push notifications, set up a cron job that
-rescans the storage periodically:
+rescans the external storage periodically using its mount ID:
 
 .. code-block:: console
 
-   sudo -E -u www-data php occ files:scan --path="/user/files/MountName"
+   sudo -E -u www-data php occ files_external:scan <mount_id>
 
-Or to rescan all files for all users (including all external storages):
-
-.. code-block:: console
-
-   sudo -E -u www-data php occ files:scan --all
-
-See :doc:`../occ_command` for the full ``files:scan`` reference. A typical
+See :doc:`../occ_command` for the full ``files_external:scan`` reference. A typical
 interval is every 15 minutes; adjust to balance freshness against server load.
 
-.. note::
-   On Nextcloud AIO the equivalent command is:
-
-   .. code-block:: console
-
-      sudo docker exec --user www-data -it nextcloud-aio-nextcloud php occ files:scan --all
-
-We also recommend configuring the background job as **Webcron** or **Cron**
-(see :doc:`../configuration_server/background_jobs_configuration`) so that
-Nextcloud's regular housekeeping runs reliably alongside any custom scan cron job.
-
 Limitation: renames are not detected reliably
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-When using periodic rescanning (option B above), the scanner cannot reliably
-detect that an entry was **renamed**. It sees the old name as deleted and the new
-name as a newly created entry. This causes **metadata loss**: all shares, tags,
-comments, and activity history associated with the old entry are permanently
-deleted from Nextcloud's database.
+Whenever Nextcloud rescans an external storage — whether via periodic cron
+(option B) or on direct access (option A setting **Once per direct access**) —
+the scanner cannot reliably detect that an entry was **renamed**. It sees the old
+name as deleted and the new name as a newly created entry. This causes
+**metadata loss**: all shares, tags, comments, and activity history associated
+with the old entry are permanently deleted from Nextcloud's database.
 
 .. warning::
    If users rename files or folders directly on the external storage (outside
-   Nextcloud), that metadata loss is unavoidable when using periodic rescanning.
-   To preserve metadata, all renames should be done through Nextcloud itself, or
-   — for SMB — use update notifications (option A) which handles renames via the
-   SMB change event stream.
+   Nextcloud), that metadata loss is unavoidable. To preserve metadata, all renames
+   should be done through Nextcloud itself, or — for SMB — use update notifications
+   (option A) which handles renames via the SMB change event stream.
 
 .. _trouble-file-encoding-ext-storages: