[fix] Recover guest clock after Mac sleep

[Fail-Safe]

Problem and behavior

When the Mac sleeps while a VM is running, the guest system clock can resume hours behind the virtual PL031 hardware clock. systemd-timesyncd may still report a prior synchronized state. Fresh signed Touch ID approvals are then correctly rejected as future-dated, despite successful fingerprint authentication on the host.

Add a guest-only recovery service and timer. Every ten seconds of guest runtime, the helper checks the expected virtual RTC and advances system time if it is more than five seconds behind, then requests a restart of the running network time-sync service. A normally scheduled guest recovers shortly after wake; this is not an instantaneous host wake callback.

• Only runs with the Try Omarchy kernel marker and expected PL031 RTC.
• Rejects malformed or slow samples, never moves system time backward, and never writes guest time to the RTC.
• Retains all existing authentication signature, replay, timestamp, and expiry checks. Uses no timestamps supplied by authentication requests or applications.
• Runs with CAP_SYS_TIME and a restricted systemd service environment.
• Enables the timer in fresh factory guests. A separate existing-guest installer performs an immediate recovery, enables the timer, and backs up replaced files without modifying PAM or enrollment.

This extends the boot-time network synchronization introduced in #143. It is independent of #182 and benefits sudo, 1Password, and other guest time-sensitive services. It assumes the Mac and the virtual RTC have correct time; small offsets and backward corrections remain NTP's responsibility.

Validation

• Focused tests cover a seven-hour pause, small offsets, refusal of backward corrections, wrong guest/RTC, invalid and delayed RTC samples, clock-setting failure, and unprivileged invocation.

• Full make test passed: 110 guest tests and 242 Swift tests, plus the project contract/shell suites. The unrelated staged-QEMU lock-inheritance check was skipped because this isolated checkout has no staged runtime. No fresh factory-image build is claimed.

• Live reproduction established: the running guest system clock lagged approximately 7 hours 22 minutes while its PL031 RTC matched the Mac, with NTPSynchronized=yes and timesyncd active.

• Existing-guest installation succeeded. The timer is active and repeated service executions complete successfully at roughly ten-second intervals. Host, guest system, and virtual RTC times match. The user confirmed Touch ID sudo worked for installation. The clocks had already converged before the new service ran, so this does not establish a live corrective step by the new helper. Subsequent live validation recorded an automatic forward correction of approximately 993 seconds (16 minutes 33 seconds) by the recovery helper. Afterward, host, guest system, and virtual RTC times matched, the timer remained active, and the user confirmed authentication was working. This establishes a real corrective step; the exact wake-to-correction latency was not measured.

• GitHub CI passed for the submitted commit.