Massive CLOCK_MONOTONIC divergence between server and client causes ALSA buffer starvation and stream closure

When a Snapserver and Snapclient are hosted on different machines with a vast difference in system uptimes (e.g., Server up for 74 days, Client up for 63 days), the engine successfully connects but the stream instantly starves ALSA and closes the pipeline.

This appears to be caused by a mathematical bounds overflow or floating-point precision loss when handling a massive diff to server offset calculated from the relative std::chrono::steady_clock (which is hard-mapped to CLOCK_MONOTONIC / system uptime on Linux).

Logs / Expected Behavior: The client accurately calculates the uptime drift (e.g., diff to server [ms]: 9.38068e+08 which correctly maps to an 11-day uptime difference). However, the massive offset appears to poison the pMiniBuffer or ALSA frame scheduling logic:

(Stream) pMiniBuffer->full() && (abs(pMiniBuffer->mean()) > 50): -68207
(Stream) Exception: Not enough frames available, requested frames: 968, available: 91
(Alsa) No chunk received for 5000ms. Closing ALSA.

Steps to Reproduce:

Run Snapserver on a host with a high uptime (>30 days).

Run Snapclient on a host with a low uptime (or a massively different uptime).

The client will calculate a huge diff to server, the buffer mean will explode, and ALSA will starve.

Validation: Moving the exact same client to the server's physical host (zeroing the CLOCK_MONOTONIC delta) fixes the stream instantly.