core/clock: update SystemClock promptly after suspend

[LamplighterPaul]

SystemClock computes a wall-clock deadline but waits using a relative QTimer. On this Linux machine, that countdown pauses during suspend, leaving minute-precision clocks stale for up to another minute after wake.

Use an absolute CLOCK_REALTIME timerfd through QSocketNotifier on Linux. Expired deadlines update the clock when the event loop resumes; TFD_TIMER_CANCEL_ON_SET also handles clock corrections. Consumers receive the existing dateChanged signal. No polling, forced redraw, or suspend hook is added. Disabled clocks disarm the timer; destruction closes it. QTimer remains the fallback.

Tested on Quickshell 0.3.1 / Qt 6.11.2, Omarchy 4.0.4, Linux s2idle:

Physical suspend	System time at resume	Packaged clock	Patched observer
16m 48s	11:15:51	10:59; corrected after 57.070s	Correct 11:15 in first sample
3m 43s	11:47:25	11:43; corrected after 17.708s	Correct 11:47 in first sample

Observers sampled every 250ms without changing clock data. The second test also ran the actual Omarchy bar with the patched binary: the same process survived suspend/unlock, and the user reported minute 47, matching the resume time. Exact visual-update latency was not measured.

Validation:

• Nine clock behavior cases pass, covering suspend at each precision, backwards corrections, disable/re-enable, precision changes, disabling during notification, successive deadlines and normal ticks. The minute regression fails on unchanged upstream c6a5160.
• Full build succeeds. Full suite: 9/10 executables pass; popupwindow::moveWithParent fails identically on unchanged upstream. All previously passing tests still pass.
• Formatting, whitespace and standard clang-tidy pass; custom tidyfox was unavailable.

Related: #559 (closed after a binding issue), and Omarchy's polling workaround. This reproduction observes SystemClock.date itself and its eventual natural recovery.

Developed with AI assistance and tested on the affected machine.