fix(main): R9 — guard the yt-dlp update throttle against a backward clock

shouldAutoCheckYtdlp compared (now - lastCheck) >= interval; a backward system-
clock correction leaves lastCheck in the future so the difference is negative and
the daily check never comes due again. Treat a future lastCheck as skewed and run
the check. The renderer scheduled-item promoter is inherently fire-once (promotion
flips the item out of 'saved'), so it can't double-fire on a backward jump — a
forward jump firing early is documented and accepted as minor.

Unit-tested. typecheck + 263 tests + eslint + prettier green.

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

CODE-AUDIT.md

@@ -1595,8 +1595,13 @@ cosmetics. `R` IDs.
   should never fire in practice. (refusing/at-rest enforcement remains an option if ever wanted.)*
 - [x] **R8 — Pretty-printed JSON for large stores.** `JSON.stringify(value, null, 2)` inflates size/write
   time for the potentially-20k-item media store (ties R3). **Fix:** compact JSON for the large stores.
-- [ ] **R9 — Clock-skew sensitivity.** `shouldAutoCheckYtdlp` and the scheduled-download promoter compare
+- [x] **R9 — Clock-skew sensitivity.** `shouldAutoCheckYtdlp` and the scheduled-download promoter compare
   `Date.now()`; a backward system-clock correction can skip or double-fire a check/schedule. Minor; note for awareness.
+  *Fixed the concrete case: `shouldAutoCheckYtdlp` now treats a `lastCheck` in the future (clock ran
+  backward → negative interval) as due, so the daily update check can't be skipped forever (unit-tested).
+  The scheduled-download promoter is inherently fire-once — each promotion flips the item out of `saved`,
+  so a backward jump only delays it and can't double-fire; a forward jump firing early is documented and
+  accepted as minor (a monotonic scheduler would be overkill for a park-until-time feature).*
 
 ---