Merge initial Fast Fetch integration

updates.md

@@ -23,6 +23,22 @@ Earlier releases remain available in the 1.0 release history, the 1.0 preview hi
 - We can synchronise selected hidden files while the normal-file allow-list is set. (#1272)
     - Normal-file exclusion patterns still apply to hidden files, and the Selector descriptions now explain their scope.
 
+### Synchronisation
+
+#### Fixed
+
+- We can reuse unchanged content more reliably after edits with the V3 Rabin–Karp chunk splitter.
+    - Corrected rolling-window processing lets boundary detection recover after an insertion. Existing content remains readable, and installing this update does not trigger a full re-chunk of our Vaults.
+    - Chunk-size values 0 and 1 now use content-defined binary boundaries below their maximum lengths, improving reuse after an insertion instead of producing fixed-length pieces.
+    - Editing or explicitly rewriting a file, recreating its chunks, or rebuilding from our files can produce different chunk boundaries and additional chunks. Older and updated devices can retain different chunk layouts; this affects reuse and storage, not the file contents.
+- We can preserve all conflict branches, including deleted branches, during Fast Setup.
+    - A fresh, complete Fast Fetch can also hand its verified progress to ordinary synchronisation before file watching resumes, reducing the first subsequent identifier scan. Existing resume cursors and On Demand chunk retrieval retain their existing behaviour.
+
+#### Changed
+
+- New setup uses the same Chunk-size recommendation of 0 across remote types, and Setting Doctor no longer recommends increasing every self-hosted V3 configuration to 60.
+    - Existing explicit and agreed values are retained. Smaller Chunks favour reuse during editing, but increase document counts and can make first uploads and large rebuilds slower. Mostly immutable binary Vaults can still benefit from a larger explicit value.
+
 ## 1.0.39
 
 20th October, 2026