Per-folder consecutive-failure backoff before rescheduling (10/30/60s)

[gnacho]

The official Nextcloud client delays the next sync run after consecutive failures per folder. FolderMan::scheduleFolder (src/gui/folderman.cpp:831-884):

• 3-4 consecutive failing syncs -> next run delayed 10s
• 5-6 -> 30s

• 6 -> 60s

The delay applies both when the folder is first scheduled and when it is already queued (startScheduledSyncSoon delayed). This prevents hammering a server that is down or a folder that keeps failing.

Current state in nextsync-rs: scheduler.rs has a capped backoff for keyring-locked (KEYRING_RETRY) and the #179 server_unreachable gate + 30s recovery probe, but there is NO per-folder counter of consecutive failures and no escalating delay. After a Failed or NetworkError, the next automatic trigger (interval/push/startup) schedules immediately (modulo the #179 gate). With a down server for hours (see the 26-Aug incident: hub.cloudless.club 502 all day), the official client would back off and scale, while ours re-runs on every trigger.

Proposed work:

1. Track consecutive_failing_syncs per folder scheduler, reset on Success/Conflict.
2. In finished(), when the outcome is a failure, compute the delay from the counter (0 / 10s / 30s / 60s, mirroring the official thresholds) and defer the next run accordingly (the Mark folder offline after N consecutive failed syncs regardless of error class #179 recovery probe at 30s should interplay: probe recovers from server-down, backoff covers any failure class).
3. Surface the counter in the folder state/UI like the official tray tooltip does.

Related: #179 (server-unreachable gate). This issue generalizes backoff beyond the server-down case.

[gnacho]

Implemented and merged in #188 (commit 4150fb9).