fix(blobs): invalidate the file_id->blob_hash cache on content swaps

The read repository's hash_cache assumed blob hashes were immutable
per file_id, but update_file_content_from_temp remaps the SAME row to
a new hash via swap_blob_hash. After a WebDAV/NC PUT overwrite,
streaming downloads (>=10 MB tier, Range requests, video playback)
kept resolving the OLD blob for the 30 s TTI window — and because
every read refreshes the TTI, a polling client could pin the stale
mapping indefinitely, eventually turning into 500s once the old
blob's refcount hit zero and GC removed it.

The write repository now holds a shared handle to the same moka cache
(clones share storage) and invalidates the entry right after every
content swap and hard delete commits — covering every present and
future caller of the write port rather than one service path. Stale
doc comments claiming the mapping was immutable (and SHA-256) fixed.

https://claude.ai/code/session_01QxwJDHqQhbMkHK333QtMme

src/common/di.rs

@@ -380,6 +380,9 @@ impl AppServiceFactory {
                 db_pool.clone(),
                 core.dedup_service.clone(),
                 folder_repo_concrete.clone(),
+                // Shared blob-hash cache: the write side invalidates entries
+                // on content swaps/deletes so reads never serve stale blobs.
+                file_read_repository.blob_hash_cache(),
             ));
 
         // I18n repository — file-system backed, gated by the locale