Make mostrecent gauge tests independent of clock resolution

[nischita44]

Refs #942

test_gauge_mostrecent and test_gauge_livemostrecent call set() twice back to back. In mostrecent mode each set() is stamped with time.time(). On a platform with coarse clock resolution, both stamps can be equal. MultiProcessCollector only replaces a value when the timestamp is strictly greater, so on a tie the result depends on the order glob returns the .db files, which is filesystem-dependent. This matches the 1 != 2.0 failure reported on Alpha.

This patches time.time in both tests to return increasing values, so the second write is always newer. Test-only change, no library code touched.

I reproduced the original failure locally by forcing a constant clock and reversed file order; both tests fail before this change and pass after.

[chrikrah]

@nischita44 the fix holds up under an independent repro: master fails only with a constant clock and reversed glob order together, and head passes that same case.

$ PYTHONPATH=. python cp_mostrecent_tie.py     # runs test_gauge_mostrecent and test_gauge_livemostrecent; Python 3.12.3
# master 9cd073c
clock=real     order=reversed run=2 failures=0 errors=0
clock=constant order=forward  run=2 failures=0 errors=0
clock=constant order=reversed run=2 failures=2 errors=0
# head 7bc7090
clock=constant order=reversed run=2 failures=0 errors=0

The probe patches time.time to return 1000.0 and prometheus_client.multiprocess.glob.glob to return sorted or reverse-sorted paths.

@csmarchbanks, this touches tests only. Is anything keeping it out of the next release?