fix(windows): avoid panic converting far-future FILETIME values

[Mapika]

Found while reviewing #60 — @Guflly noted in passing that "the full Windows suite still hits the existing far-future FILETIME panic on main." They are right, and the reason it survived this long is the more interesting half.

The panic

Some(UNIX_EPOCH + Duration::new(secs, nanos))

Add for SystemTime panics when the result is unrepresentable. filetime_to_u64(u32::MAX, u32::MAX) is u64::MAX, which works out to roughly year 58,000. A Windows SystemTime is itself FILETIME-backed and ends near year 30828, so it overflows and takes the whole scan down.

Linux never sees it: SystemTime there is a timespec with i64 seconds, which swallows the value happily. That platform split is exactly why a test named filetime_to_system_time_far_future_no_panic has been sitting there green.

Fixed with checked_add. The function already returns Option and callers already handle None, so nothing downstream changes.

Why no test caught it

cargo test runs only in the Linux quality job. The platform matrix jobs run cargo build --release --target ... and a smoke test — no tests. So every #[cfg(windows)] and #[cfg(macos)] test in the repo has been compiled and never executed, on any runner.

This PR runs the suite on the platform targets that are natively runnable:

target	runs tests	why
x86_64-unknown-linux-gnu	no	already covered by quality
x86_64-apple-darwin	no	cross-compiled on an arm64 runner, not runnable
aarch64-apple-darwin	yes	native
x86_64-pc-windows-msvc	yes	native

The old assertion was assert!(result.is_some()) — asserting the very thing that overflows, which is what made this a panic rather than a failure. It now asserts None, the correct Windows answer.

Verification

cargo fmt, clippy -D warnings, 169 tests, and both cross-target checks pass locally. But a #[cfg(windows)] fix cannot be genuinely verified from Linux — the CI change is the verification. If the Windows job goes green here, it is the first time these tests have ever run.