fix(favorites): save server favourites through to the cache (DR-115)

The hybrid favourites read went straight to the online repository on a
cache miss and dropped the result on the floor. Every other read path
persists what it fetches, so this one made the favourites page re-query
the server on every visit — and left the offline mirror (DR-114) empty on
a fresh install, since this is the path that fills it.

It now goes through get_favorites_server_only, which saves through on the
way back.

The command had a matching hole: with nothing cached it returned the empty
result, painting "Nothing favourited yet" at a viewer whose favourites
were simply marked on another client. It now asks the repository for a
real answer instead of an empty state it would correct a round trip later.

TRACES: UR-067 | DR-115

src-tauri/src/commands/repository.rs

@@ -866,6 +866,23 @@ pub async fn repository_get_favorites(
         return Ok(cache_result);
     }
 
+    // Nothing cached yet — a fresh install, or a viewer whose favourites were
+    // all marked on another client. Returning the empty result here paints
+    // "Nothing favourited yet — tap the heart on anything you like", which is a
+    // *wrong* answer, corrected a server round trip later when the background
+    // refresh fires `favorites-changed`. Ask the repository for a real answer
+    // instead: its `get_favorites` is exactly this read — cache first, server on
+    // a miss, saving through — and it applies the same DR-080 gate.
+    //
+    // TRACES: UR-067 | DR-115
+    if !cache_result.has_content() {
+        debug!("[Favorites] Nothing cached; answering from the server");
+        return repo
+            .get_favorites(scope, options)
+            .await
+            .map_err(|e| format!("{:?}", e));
+    }
+
     let repo_bg = repo.clone();
     let cached_ids: std::collections::HashSet<String> =
         cache_result.items.iter().map(|i| i.id.clone()).collect();