fix(sync): use microseconds for MAX_TIMESTAMP_FUTURE_SHIFT (#99)

## 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 #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

- [x] Self-review.
- [ ] Documentation updates following the [style
guide](https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#appendix-a-full-conventions-text),
if relevant.
- [x] Tests if relevant.
- [x] All breaking changes documented.

Author: cbenhagen

src/sync.rs

@@ -40,7 +40,7 @@ pub type PeerIdBytes = [u8; 32];
 
 /// Max time in the future from our wall clock time that we accept entries for.
 /// Value is 10 minutes.
-pub const MAX_TIMESTAMP_FUTURE_SHIFT: u64 = 10 * 60 * Duration::from_secs(1).as_millis() as u64;
+pub const MAX_TIMESTAMP_FUTURE_SHIFT: u64 = 10 * 60 * Duration::from_secs(1).as_micros() as u64;
 
 /// Callback that may be set on a replica to determine the availability status for a content hash.
 pub type ContentStatusCallback =
@@ -1785,6 +1785,32 @@ mod tests {
         Ok(())
     }
 
+    /// Regression: `MAX_TIMESTAMP_FUTURE_SHIFT` must be on the same unit scale as
+    /// `system_time_now()` (Unix epoch **microseconds**). A millisecond-scaled constant
+    /// only allows ~0.6s of future slack and would reject this insert.
+    #[tokio::test]
+    async fn test_future_timestamp_accepts_one_second_skew() -> Result<()> {
+        let mut rng = rand::rng();
+        let mut store = store::Store::memory();
+        let author = Author::new(&mut rng);
+        let namespace = NamespaceSecret::new(&mut rng);
+        let mut replica = store.new_replica(namespace.clone())?;
+        let key = b"skew";
+        let skew_micros: u64 = Duration::from_secs(1).as_micros() as u64;
+        let now = system_time_now();
+        let record = Record::from_data(b"ahead", now + skew_micros);
+        let entry = SignedEntry::from_parts(&namespace, &author, key, record);
+        replica
+            .insert_entry(entry.clone(), InsertOrigin::Local)
+            .await?;
+        assert_eq!(
+            get_entry(&mut store, namespace.id(), author.id(), key)?,
+            entry
+        );
+        store.flush()?;
+        Ok(())
+    }
+
     #[tokio::test]
     async fn test_insert_empty() -> Result<()> {
         let mut store = store::Store::memory();