wal: fix WAL lock on Android by using fs4 flock instead of std try_lock (#9226)

`dir.try_lock()` resolves to the inherent `fs_err`/`std` `File::try_lock`,
which Rust's stdlib gates to a fixed target list that excludes
`target_os = "android"` (1.89+). On Android it returns
`ErrorKind::Unsupported` ("try_lock() not supported"), so opening a WAL —
and thus creating/loading a shard via qdrant-edge — fails.

Dispatch explicitly to `fs4::FileExt::try_lock` on the underlying
`std::fs::File`, which issues a direct `flock(LOCK_EX | LOCK_NB)` syscall
that Android supports. This restores the pre-#8770 behavior. UFCS is needed
because fs4's trait method collides by name with the inherent one (which
otherwise wins method resolution).

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

lib/wal/src/lib.rs

@@ -152,7 +152,16 @@ impl Wal {
             dir
         };
 
-        dir.try_lock()?;
+        // Use `fs4`'s `flock(2)`-based lock rather than `dir.try_lock()`.
+        //
+        // `dir.try_lock()` resolves to the inherent `fs_err`/`std` `File::try_lock`,
+        // which is gated to a fixed list of targets in stdlib and returns
+        // `ErrorKind::Unsupported` ("try_lock() not supported") on others — notably
+        // Android. `fs4::FileExt::try_lock` issues a direct `flock(LOCK_EX | LOCK_NB)`
+        // syscall, which Android supports. We call it via UFCS on the underlying
+        // `std::fs::File` because the trait method collides with the inherent one
+        // (which would otherwise win method resolution).
+        fs4::FileExt::try_lock(dir.file())?;
 
         // Holds open segments in the directory.
         let mut open_segments: Vec<OpenSegment> = Vec::new();