Mark folder offline after N consecutive failed syncs regardless of error class

[gnacho]

Problem

The folder/account offline state is only reached through SyncOutcome::NetworkError (#162), i.e. when the remote ensurer gets a transport error. Other persistent failure modes - HTTP 5xx from the server, WebDAV errors, a broken reverse proxy, repeated engine crashes - keep ending as Failed forever: the summary still reads "Connected" and the folder retries on every trigger without ever telling the user the account is effectively unreachable.

Reference pattern: Iotas

Iotas keeps a SYNC_FAIL_OFFLINE_THRESHOLD = 2 counter: two consecutive failed sync runs flag offline = true (shown in the UI), and the next successful run clears it ("Recovered connectivity"). Simple, and it covers every error class without having to classify each one.

Proposal

• Count consecutive Failed (and NetworkError) outcomes per folder scheduler.
• After N consecutive failures (N=2 or 3), transition to the existing Offline state with a message like "Synchronization is failing repeatedly - check the server".
• Reset the counter on any outcome that ran the engine (Success / Conflict).
• Keep the existing per-error states (AuthFailed, KeyringLocked, DeleteReview) taking precedence as they do today.

Acceptance criteria

• Two consecutive Failed outcomes move the folder to Offline
• A later Success clears the flag and the counter
• AuthFailed / KeyringLocked / DeleteReview still win over Offline
• Tests: counter increments only on back-to-back failures, resets on success

[gnacho]

Refinement from real-world failure (2026-08-26): hub.cloudless.club returned HTTP 502 for hours because the backend LXC lost its DHCP lease (reverse proxy 502, not a transport error). The account stayed 'Connected' and every 10-min interval retried all folders, each ending Failed.

Proposal: before classifying a Failed outcome, run a cheap server health probe (e.g. GET /status.php with a short timeout, or reuse the existing remote ensurer). If the probe fails (5xx, timeout, transport) mark the folder/account Offline immediately instead of waiting for N consecutive failures - the account is effectively unreachable. Keep the N-failure counter as a fallback for error classes the probe cannot reach. A 2xx probe keeps the current Failed state (the error is folder-specific, not connectivity).

[gnacho]

Second half of the fix: recovery polling. When a folder goes Offline (server unreachable), the scheduler must not wait for the next 10-min interval trigger to notice the server came back. Schedule a lightweight health probe every 30-60s against the account server; when it answers (2xx) clear the Offline state, mark the account Connected again and run the pending reconciliation. Reuses the same health-probe as the failure classification (GET /status.php for Nextcloud, equivalent for OpenCloud) with a short timeout (~5s), so a dead server costs one cheap probe per poll instead of a full nextcloudcmd spawn. This also keeps the other accounts healthy: an Offline account stops taking the global permit, so the healthy account's folders no longer sit on 'Waiting for another folder to finish...'.

[gnacho]

Implemented and merged in PR #187 (commit 3ef1252, release v0.2.6).