release: prepare production client deployment

docs/implementation-plan.md

@@ -105,7 +105,7 @@ follow-up task.
 ### Actions
 
 1. Implement qBittorrent cookie authentication and capability adapters for
-   supported 4.5–4.6 and 5.x APIs.
+   supported 4.4–4.6 and 5.x APIs.
 2. Implement on-demand torrent summaries, scoped hash lookup, lazy complete
    content trees, v1/v2 identity validation, torrent export, stopped add,
    selection application, recheck monitoring, and entry-only deletion.

docs/service-apis.md

@@ -6,7 +6,7 @@ shapes.
 
 ## qBittorrent Web API
 
-The implementation targets supported qBittorrent 4.5–4.6 and 5.x releases and
+The implementation targets supported qBittorrent 4.4–4.6 and 5.x releases and
 detects the application and Web API versions at startup. The authoritative
 references are the official [5.0 WebUI API](https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-%28qBittorrent-5.0%29)
 and [4.1-compatible WebUI API](https://github.com/qbittorrent/qBittorrent/wiki/WebUI-API-%28qBittorrent-4.1%29).
@@ -83,6 +83,12 @@ The folder's native ID becomes `route_id`. Multi-device, send-only,
 receive-only, out-of-root, or ambiguous folders are reported as unsupported and
 left unchanged.
 
+Syncthing may serialize a folder path relative to its home as `~/...`. The
+client normalizes that notation beneath the configured API-visible sync root
+before applying the API-to-local root mapping. Deployments must mirror
+Syncthing's nested bind mounts into the client so the normalized API path and
+the client filesystem path refer to the same bytes.
+
 Provisioning uses idempotent device and folder configuration updates. Each
 client receives its peer device ID and optional advertised addresses
 (`dynamic` by default). It changes only the specific device/folder objects