fix(fuse): a copy right after a save waits for the edit (B256)

close(2) returns before the kernel sends release, and release takes the
write handle out of the open writes a few milliseconds before the
revision is in the queue. A `pdfs copy` checked in that gap found the
edit nowhere and copied the version Drive had. A folder copy looked only
at the queue, so it also missed files below it still open with unsaved
writes.

release now keeps the inode in State::releasing until the revision is
queued. A copy refuses a file or folder with unsaved writes, or a
release still queueing, at it or below it, and a move checks the same
set.

crates/pdfs-fuse/src/state.rs

@@ -266,6 +266,11 @@ pub(crate) struct State {
     pub(crate) next_ino: u64,
     /// Shared write state keyed by inode. Concurrent writers share the scratch file.
     pub(crate) active_writes: HashMap<u64, WriteHandle>,
+    /// Inodes whose last write handle `release` has taken out of
+    /// [`State::active_writes`] and is still queueing. `close(2)` returns
+    /// before that, and in between the edit is in neither the handles nor the
+    /// queue, so a check for changes not on Drive yet looks here too.
+    pub(crate) releasing: HashSet<u64>,
     /// Maps file handle id (fh) to inode (ino). Read-only opens use fh 0 and
     /// have no entry here.
     pub(crate) handles: HashMap<u64, u64>,
@@ -428,6 +433,7 @@ impl State {
             roots: HashSet::new(),
             next_ino: FALLBACK_INO,
             active_writes: HashMap::new(),
+            releasing: HashSet::new(),
             handles: HashMap::new(),
             next_fh: 1,
             dir_snapshots: HashMap::new(),