feat(fuse): answer copy_file_range from bytes already on this machine

A copy inside the mount went through the kernel's read/write loop, one
FUSE round trip per page, because copy_file_range answered ENOSYS. The
daemon now copies a range whose source bytes are local (an open write
handle, a queued write, the cache) into the destination's scratch file,
the same way write stages them. A range it would have to download gets
EOPNOTSUPP, which makes the kernel copy that one call itself and keeps
the operation enabled. The copy still uploads: Drive cannot copy into a
file cp has already created.

In the simulation, a warm cp of a 256 MiB file went from about
100 MiB/s to about 450 MiB/s (debug build).

docs/CHANGELOG.md

@@ -34,6 +34,10 @@ scratch (user data in `staging/` and `recovery/` is never touched by this).
   Proton Drive counts it, including items in the trash. From a terminal: `pdfs du PATH`.
 
 ### Changed
+- **Copying a file inside the mount is faster** when the computer already has the file, for
+  example with `cp` or a file manager: the copy is made on this computer, about four times
+  faster for a 256 MiB file, instead of going through the mount page by page. A file that is
+  only on Proton Drive is copied as before. The copy is then uploaded as usual.
 - **Reorganised documentation, now also on the
   [wiki](https://github.com/narrrl/proton-drive-linux/wiki).** A new
   [Getting started](https://github.com/narrrl/proton-drive-linux/wiki/Getting-Started) page and