fix(sync): use microseconds for MAX_TIMESTAMP_FUTURE_SHIFT

[cbenhagen]

Description

Fixes future timestamp validation so the allowed skew matches the documented ten-minute policy.

Entry timestamps and system_time_now() are Unix epoch microseconds. MAX_TIMESTAMP_FUTURE_SHIFT was derived using milliseconds, so the effective cap was about 600 ms instead of ten minutes. The constant now uses Duration::from_secs(1).as_micros() so it is expressed in the same unit as wall time.

Adds test_future_timestamp_accepts_one_second_skew, a regression test that would fail if the slack constant were still on millisecond scale: it inserts an entry one second in the future, then asserts the stored entry matches (round-trip), not only that insert succeeds.

Breaking Changes

None

Notes & open questions

• Closes MAX_TIMESTAMP_FUTURE_SHIFT unit mismatch causes validate_entry to reject entries from peers with >600 ms wall-clock skew #97
• Considered introducing a UnixEpochMicros newtype and threading it through the public API so unit mix-ups are harder to repeat, but that would be a breaking change with little extra correctness beyond fixing the constant, so this PR only corrects the scale of MAX_TIMESTAMP_FUTURE_SHIFT and adds a regression test.

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.