test(db): truncate expected timestamp to the fence's microsecond precision

[troyhoffman-oss]

The commit message has the full reasoning; short version:

fence_starts_closed_and_opens_on_advance asserts verified_through() returns exactly the DateTime<Utc> passed to advance(). ReplicaFence stores the fence as unix microseconds in an AtomicI64, so that round-trip drops any sub-microsecond remainder — the assertion is really testing the host clock's resolution. It passes where Utc::now() yields microseconds and fails on Linux, where it yields nanoseconds, whenever the sampled instant is not a whole microsecond.

Build the expected value at the fence's own precision instead. Truncating ts at the source also keeps the neighbouring inclusive-boundary assertions (covers(ts), covers(ts ± 1s)) exercising the value that was actually stored.

Test-only. Production callers reach the fence through covers(), a comparison rather than an equality check, which is unaffected.

Testing

cargo test -p buzz-db --lib on a Linux host.

Before (on main):

running 1 test
test replica_fence::tests::fence_starts_closed_and_opens_on_advance ... FAILED

---- replica_fence::tests::fence_starts_closed_and_opens_on_advance stdout ----
thread 'replica_fence::tests::fence_starts_closed_and_opens_on_advance' panicked at crates/buzz-db/src/replica_fence.rs:526:9:
assertion `left == right` failed
  left: Some(2026-07-28T13:16:05.977156Z)
 right: Some(2026-07-28T13:16:05.977156032Z)

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 223 filtered out

After:

running 1 test
test replica_fence::tests::fence_starts_closed_and_opens_on_advance ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 223 filtered out

Full crate suite, three consecutive runs: 85 passed; 0 failed; 139 ignored each time. cargo fmt --check and cargo clippy -p buzz-db --all-targets clean.