fix: keep the daemon's timers on a monotonic clock

[lyager]

Problem

Every deadline the daemon keeps is derived from current_time_millis(), which reads SystemTime: record TTLs and refresh points, probe and announce schedules, retransmissions, delayed responses, resolver timeouts and the periodic IP check. If the system clock is stepped while the daemon runs, all of them move with it.

A backwards step parks every deadline for the size of the step: the IP check stops running, a service registered just before the step is never announced, new addresses are never picked up, and register() has already reported success. A forwards step has the mirror effect: every timer fires at once and every cached record looks expired.

We hit the backwards case on an embedded device whose RTC driver loads a few seconds after the responder starts. The kernel re-seats the wall clock from the RTC at that point, and when the RTC held a date in the past the responder went silent on every interface for the rest of the uptime, with no error logged anywhere. Any host where NTP or an operator sets the clock back is exposed the same way.

Change

Use std::time::Instant for points in time and Duration for the deltas between them, which is what the standard library provides for exactly this distinction.

• current_time_millis() is removed. Fields and parameters that carried its value (created, expires, refresh, probe start_time/next_send, ReRun/DelayedResponse::next_time, resolver timeouts, the timer heap) are Instant.
• The 0 sentinels meaning "no time" (write_record, add_answer_at_time, the answers' per-record time, the IP-check timer) become Option<Instant>, since an Instant has no zero.
• Deltas use the standard saturating operations (saturating_duration_since), so the two subtractions that could underflow when a record was already past its expiry are covered too. The run loop's poll timeout is timer.saturating_duration_since(now).max(1 ms).
• TTLs on the wire are still remaining seconds measured from the record's creation, so packets are unchanged. The multicast rate limit keeps its u64 constant and is compared as a Duration at its single use site.
• Seven const fns become fn, because Instant comparison and arithmetic go through traits. None was used in a const context.

Nothing in the crate needs the wall-clock time; no absolute timestamp leaves the crate.

Testing

• cargo test passes (lib, integration, doc); cargo clippy --all-targets and cargo fmt --check are clean.
• The device scenario above was reproduced and diagnosed against v0.21.4 (daemon registers at t≈2 s, kernel steps the clock back ~5 months at t≈3–7 s, no announce for the rest of the uptime). The fixed crate has not yet been run on that device; I will report back once it has.

Notes

• Instant is CLOCK_MONOTONIC on Linux and does not advance during suspend, so a cache on a machine that sleeps will trust records for longer than their TTL after waking. The SystemTime version had the opposite failure on wake (everything expires at once). A re-query on resume is the usual answer if that matters to a user.
• A smaller alternative exists — keep current_time_millis() and anchor it to an Instant — which fixes the stall in one function but keeps milliseconds as untyped integers. I'm happy to switch to that if you prefer the minimal diff.

[keepsimple1]

Thank you for the PR! It's a real improvement, looks good!