fix(connectivity): drive reachability from real repository traffic

The offline/online switch was janky because two independent systems decided
"online" and never communicated:

- ConnectivityMonitor owned is_server_reachable (drove the UI banner) but
  learned reachability only from a standalone /System/Info/Public ping loop
  and from auth/login calls.
- HybridRepository served all real data by racing cache-vs-server but never
  read or wrote reachability.

So the banner reflected a side-channel poller, not the system the user actually
experienced: a successful ping could read "online" while authenticated data
calls 401'd or timed out, and three different timeout regimes (5s ping / 30s
data / 100ms cache race) flapped against each other.

Unify into a single source of truth:

- Extract a cheap, cloneable ConnectivityReporter that owns all reachability
  transitions and event emission.
- OnlineRepository reports the outcome of every server request to the reporter,
  classified via RepoError: Ok/Authentication/NotFound/Server => reachable
  (the server answered), Network => offline candidate, Database/Offline =>
  ignored (not a server signal).
- Time-window debounce (OFFLINE_CONFIRM_WINDOW = 5s): flip offline only after
  sustained network failure; recover instantly on the first success.
- Demote the ping loop to an offline-only recovery probe (no online polling;
  real traffic is the signal when online).
- Frontend: navigator.onLine is now advisory (triggers a recheck instead of
  forcing offline); removed the dead markReachable/markUnreachable store methods.

Docs updated (README, 07-connectivity, 03-data-flow, 02-svelte-frontend) to
describe the new model and fix pre-existing drift (HTTP client is 30s timeout +
5s ping, not the documented 10s/base_url).

Tests: 12 connectivity tests (debounce, instant recovery, RepoError
classification through report_outcome). Full suite: 398 Rust + 384 frontend
passing, svelte-check clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/architecture/02-svelte-frontend.md

@@ -176,7 +176,10 @@ classDiagram
         -server_url: String
         -user_id: String
         -access_token: String
+        -connectivity: Option~Arc~ConnectivityMonitor~~
         +new()
+        +with_connectivity()
+        -report_outcome()
     }
 
     class OfflineRepository {
@@ -192,10 +195,9 @@ classDiagram
     class HybridRepository {
         -online: Arc~OnlineRepository~
         -offline: Arc~OfflineRepository~
-        -connectivity: Arc~ConnectivityMonitor~
         +new()
-        -parallel_query()
-        -has_meaningful_content()
+        -parallel_race()
+        -cache_with_timeout()
     }
 
     MediaRepository <|.. OnlineRepository
@@ -214,6 +216,7 @@ classDiagram
    - Returns cache result if it has meaningful content
    - Falls back to server result otherwise
    - Background cache updates planned
+   - **Connectivity feedback**: `OnlineRepository` reports the outcome of every server request to the `ConnectivityMonitor` (classified via `RepoError`). This is the source of truth for the offline/online banner — see [07-connectivity.md](07-connectivity.md). The frontend `connectivity` store is a pure reflection of the resulting events; `navigator.onLine` is only an advisory hint that triggers an immediate recheck.
 
 2. **Handle-Based Resource Management** (`repository.rs` commands):
    ```rust