Allow injecting the clock and a clock-skew leeway for exp/nbf verification

[zshenker]

Problem

Token::verify_claims always reads the system clock for the exp and nbf checks. Callers with their own time source have to turn those checks off and reimplement them. Examples include deterministic simulation, tests, and services with a trusted clock.

Change

VerificationOptions gains a new field, now: Option<u64>, with a builder method, now(timestamp). When it's set, verify_claims uses that value instead of the system clock. When it's unset, the system clock is used as before.

VerificationOptions::leeway(seconds) tolerates clock skew in the same pass: a token stays valid up to leeway seconds after exp and becomes valid leeway seconds before nbf (saturating; default 0).

The informational helpers (Token::is_expired, expires_in, is_valid_yet and the RegisteredClaims equivalents) are unchanged and still use the system clock.

This PR is based on main. A dry merge shows no conflicts with #6, #8, #9 or #10. The tests are in a new src/tests_clock.rs to avoid conflicts with the edits #6 makes to src/tests.rs.

Tests

• test_injected_clock_drives_exp_and_nbf checks the nbf and exp boundaries under an injected time. The token is rejected one second before nbf, accepted at nbf and at exp − 1, and rejected at exp.
• test_system_clock_is_the_default checks that the system clock is still used when now is unset.
• test_leeway_extends_exp_and_nbf_in_the_permissive_direction and test_leeway_saturates cover the leeway boundaries and saturation.

cargo fmt --check, cargo clippy --all-targets -- -D warnings and cargo test all pass: 59 unit tests and 73 doctests.

🤖 Generated with Claude Code