fix: round scru128 timestamp on pack to stop id roundtrip loss

[cablehead]

Problem

.id unpack $id | .id pack did not roundtrip for about 3% of scru128 ids. The prefix matched and the low bits diverged, for example:

03gmmrhqljv8bnulus79wipck -> 03gmmrhqleed8w8bsl6cn17tg

This is what made the .id roundtrip assertion in tests/test_xs_nu.nu flaky, since it minted one fresh id per run and tripped roughly 1 run in 35.

Mechanism

.id unpack emits the timestamp as f64 seconds (scru128.rs, ms / 1000.0) and the nu def routes it through a nanosecond datetime. .id pack hands f64 seconds back to the Rust packer, which computed milliseconds with (timestamp * 1000.0) as u64. The as u64 cast truncates toward zero. When the reconstructed f64 millisecond value landed just under an integer (for example 1785966646157.9998 for a true 1785966646158), it dropped a millisecond. That corrupts the 48-bit timestamp field and repacks to a different id.

Fix

Round to the nearest millisecond instead of truncating, in both pack_from_json and pack (src/scru128.rs). The nu datetime detour keeps the value within sub-nanosecond of the true millisecond, so rounding recovers it exactly.

Tests

Both roundtrip tests now pin the known failing ids and sweep 2000 fresh ids per run, replacing the single random-id check. Measured loop failures: 56/2000 before, 0/2000 after. The Rust test_scru128_round_trip and the e2e tests/test_xs_nu.nu both fail reliably on the old code and pass on the fix.

cargo fmt, cargo clippy -D warnings, and cargo test are green. The docs (astro) step of check.sh requires Node >=22.12 and is not run here (local Node is 18.19.1); that is an environment gate, unrelated to this change.