Fix sync worker stall on persistent errors

[Left024]

Credits

This change was made by DeepSeek V4 Pro and has been manually tested by @Left024 on device — verified working correctly.

Problem

When background sync encounters an error (e.g., FreshRSS credentials expire, network issues), the SyncWorker enters infinite exponential backoff (capped at 5h). Users experience this as "auto-refresh stopped working completely" — it never recovers until manual refresh or app restart.

Additional issues:

• After switching accounts, periodic task carries the old accountId but dispatches via "current account" type, causing permanent type-mismatch failure
• ReaderWorker retries indefinitely when any article full-content fetch fails, blocking the entire POST_SYNC_WORK chain (KEEP policy)
• Changes to sync interval / Wi-Fi-only / charging-only settings only update the database but never reschedule the periodic task

Root Cause

1. SyncWorker: sync() returns Result.Retry() → WorkManager exponential backoff. Each retry doubles the wait, permanently suspending the normal sync interval rhythm
2. Account mismatch: enqueuePeriodicWork bakes accountId into inputData, but doWork() uses rssService.get() (current account type) — cross-account dispatch fails with type checks
3. ReaderWorker: any failed article fetch → infinite retry → POST_SYNC_WORK never completes → subsequent syncs can't enqueue new ReaderWorker/WidgetUpdateWorker
4. Settings not applied: sync settings changes only write to DB; rescheduling only happens at app restart via initSync()

Changes

• SyncWorker: capping retries at 3 attempts (1 initial + 2 backoff retries), then returning Result.Failure — for periodic tasks this triggers resetPeriodic(), allowing the next sync interval to proceed normally. Also injecting AccountService to dispatch by inputData.accountId instead of current account
• ReaderWorker: capping retries to avoid blocking POST_SYNC_WORK chain indefinitely; missing full content will be re-fetched by the next sync cycle
• AbstractRssRepository: extracting reschedulePeriodicWork(account) from initSync() for external reuse
• AccountViewModel: calling reschedulePeriodicWork immediately on account switch and sync setting changes, no longer requires app restart
• FeverRssService: changed Result.Failure() to Result.Retry() for behavior consistency with Local/GoogleReader

[Left024]

追加修复:周期任务 Next scheduled time 永久显示错误日期

现象

故障排除页面的 Worker infos 中，周期任务 "Next scheduled time" 有时显示为 Aug 17（无论真实日期是多少），且一旦出现就永不恢复。

根因

enqueuePeriodicWork 在 App 重启时对 ENQUEUED 状态使用 UPDATE 策略，保留了旧 WorkSpec 中的 lastEnqueueTime。若某次设备时钟异常（重启后未同步 / 时区切换）期间，reschedule() 将错误时间写入 lastEnqueueTime，此后每次重启都用 UPDATE 保留旧值，calculateNextRunTime() = lastEnqueueTime + 30min 永远停留在那一天。

修复

• SyncWorker.enqueuePeriodicWork: 仅 RUNNING 用 UPDATE，其他状态用 CANCEL_AND_REENQUEUE 重建 WorkSpec
• WidgetUpdateWorker.enqueuePeriodicWork: 同样处理

每次 App 启动时 lastEnqueueTime 重置为当前系统时间，污染不再累积。

测试

@Left024 已在设备上验证修复有效。