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

docs/specs/favorites-browsing.md

@@ -376,6 +376,14 @@ Two things landed differently from the design above, both forced by where the
    through a narrow `FavoriteSink` trait so it can be tested against a recording
    double instead of a forty-method `MediaRepository` mock.
 
+3. **The command falls back to `HybridRepository::get_favorites` when nothing is
+   cached.** The two-phase read alone paints "Nothing favourited yet" on a fresh
+   install and corrects it a server round trip later, which is a wrong answer
+   shown to the user. An empty cache leg therefore defers to the repository's
+   own cache-first-then-server read. That read was also fixed to *save through*
+   on a server hit — without it the page re-queried the server on every visit
+   and the DR-114 mirror was never filled by this path.
+
 Also as built: `DatabaseService` is not object-safe (generic methods), so the
 drain takes `Arc<RusqliteService>` like the rest of the storage code, and
 `get_items`' endpoint construction was extracted to `build_get_items_endpoint`