Route automatic staging through qB data mounts

docs/deployment-preflight.md

@@ -78,11 +78,11 @@ python3 scripts/preflight-deployment.py ... \
 
 ## What it checks
 
-- Each configured qBittorrent and Syncthing API root resolves through Docker
-  mounts to the same host path as the matching client local root.
-- The client uses one bind mount for its qBittorrent and Syncthing roots, so
-  hard-link staging remains possible rather than silently falling back to a
-  space-consuming copy.
+- The future automatic `routes/<route-id>` path resolves through Docker mounts
+  to the same host path as its client-side mapping.
+- That future route path and qBittorrent content root use one client bind
+  mount, so hard-link staging remains possible rather than silently falling
+  back to a space-consuming copy.
 - The token, qB password, and Syncthing API-key files are non-empty regular
   files with no group/world permissions.
 - The client image can read its configuration and reports usable permissions,
@@ -90,12 +90,11 @@ python3 scripts/preflight-deployment.py ... \
 - qBittorrent authentication/version compatibility and Syncthing
   authentication/device identity are healthy from the client container.
 
-In particular, `syncthing.api_root` must refer to the Syncthing **shared-data
-mount**, not its configuration volume. For example, if Syncthing mounts its
-config at `/var/syncthing` and data at `/var/syncthing/Sync`, use
-`api_root = "/var/syncthing/Sync"` when `local_root` maps that data directory.
-This prevents a route folder being created in the config volume while the
-client writes nonce files into the data volume.
+In particular, if `syncthing.api_root` is the Syncthing configuration root,
+bind its `routes` subdirectory from a dedicated directory beneath qB's data
+root and add a `local_path_overrides` mapping for that exact API path. This
+prevents automatic route folders being created on a small configuration
+filesystem while the client expects to hardlink from the qB data mount.
 
 ## Failure handling