KeepOptions::apply and SnapshotFile::time expose jiff::Zoned without re-exporting jiff

[arcker]

Summary

KeepOptions::apply takes &jiff::Zoned:

pub fn apply(&self, snapshots: Vec<SnapshotFile>, now: &Zoned) -> RusticResult<Vec<ForgetSnapshot>>;

…and SnapshotFile::time returns Zoned too. To call either, a downstream crate has to add jiff to its own Cargo.toml and use the same major version rustic_core was built against — otherwise the Zoned type is technically a different type and the call doesn't compile.

This is a classic leaked-dependency footgun: a cargo update of jiff upstream can break consumers in a way that's hard to diagnose.

Suggestion

Either:

1. Re-export jiff at the crate root: pub use jiff; in lib.rs. Consumers can then write rustic_core::jiff::Zoned and stay version-locked automatically.
2. Wrap timestamps in an opaque type — e.g. RusticTimestamp(jiff::Zoned) with constructors and a chrono-/jiff-conversion API. Heavier, but isolates the public API from the time-crate ecosystem entirely.

Option 1 is cheap and solves the immediate version-mismatch hazard. Option 2 is a more deliberate design choice that frees future versions of rustic_core to swap or add time backends.

Context

cargo add jiff works around this in the short term, which is what we did. Flagging it because the fix in rustic_core itself is a one-liner (re-export) and would help other consumers.