Support requesting VFS hydration; fix Android TLS cross-compilation

Correcting the previous commit: I claimed VFS placeholders could not be
downloaded. That was wrong. The desktop client exposes a socket at
$XDG_RUNTIME_DIR/Nextcloud/socket speaking newline-delimited
COMMAND:argument, and MAKE_AVAILABLE_LOCALLY:<path> does fetch the file.
Verified against client 4.0.7: a 1-byte stub became a real 2.8MB file in
2.8 seconds.

Implemented as dr-sync-nextcloud::desktop_client, deliberately optional.
Android has no desktop client, no XDG_RUNTIME_DIR socket and no
placeholders, so detect() returns None there and callers fall back to the
connector. It earns its place only because it is ~30 lines with no
dependencies: where a library already lives in a VFS folder, asking the
client to fetch beats downloading a second copy over WebDAV and leaving
the client's placeholder state inconsistent.

What this does not change: hydration is whole-file, so it suits the
original tier and never browsing. Filling a grid this way downloads the
entire library. Range extraction remains the only mechanism satisfying
FR-NC-3, and ARCH §9.0 now says so precisely.

Also fixes two real Android build failures found by cross-compiling:

  - reqwest's `rustls` feature defaults to aws-lc-rs, whose aws-lc-sys
    crate is C and fails under the NDK — exactly the pain D1 chose Rust
    to avoid. Switched to rustls-no-provider + ring, installing the
    provider in the constructor so no caller can build a client that
    panics on first use.
  - ring itself needs CC/AR per target; cargo-ndk sets only the linker.
    Added them to the container.

87 tests passing. dr-sync-nextcloud cross-compiles for aarch64-linux-android.

docker/android/Dockerfile

@@ -107,6 +107,19 @@ ENV CARGO_TARGET_AARCH64_LINUX_ANDROID_LINKER=${NDK_BIN}/aarch64-linux-android${
 ENV CARGO_NDK_PLATFORM=${MIN_API} \
     ANDROID_PLATFORM=${MIN_API}
 
+# Crates with C or assembly components (ring's crypto core, and anything else
+# using the cc crate) need a compiler and archiver per target, not just a
+# linker. cargo-ndk sets the linker only, so these are set explicitly —
+# otherwise `ring` fails its build script and TLS cannot be built at all.
+ENV CC_aarch64_linux_android=${NDK_BIN}/aarch64-linux-android${MIN_API}-clang \
+    AR_aarch64_linux_android=${NDK_BIN}/llvm-ar \
+    CC_armv7_linux_androideabi=${NDK_BIN}/armv7a-linux-androideabi${MIN_API}-clang \
+    AR_armv7_linux_androideabi=${NDK_BIN}/llvm-ar \
+    CC_x86_64_linux_android=${NDK_BIN}/x86_64-linux-android${MIN_API}-clang \
+    AR_x86_64_linux_android=${NDK_BIN}/llvm-ar \
+    CC_i686_linux_android=${NDK_BIN}/i686-linux-android${MIN_API}-clang \
+    AR_i686_linux_android=${NDK_BIN}/llvm-ar
+
 # Shared cargo registry cache — bind-mount over this to persist across runs.
 VOLUME ["/opt/cargo/registry"]