fix: relative dates roll over month ends like Git, instead of clamping - #2910

Fixes #2909.

gix_date::parse() used to merge all relative count-unit pairs into a single jiff::Span and subtract it with jiff's calendar arithmetic, which clamps to the end of the target month. Git's approxidate() instead steps down tm_mon/tm_year-style calendar fields while leaving the day-of-month alone, and lets mktime(3) roll a day beyond the end of the month over into the following month. Around month ends the two disagree by 1–3 days: one month before 2026-03-31 is 2026-03-03 to Git, not 2026-02-28.

What changed

• parse_ago() now returns the recognized <count> <unit> pairs in input order instead of one merged Span.
• subtract_pairs() applies them the way Git does: second through week subtract a fixed number of seconds from the timestamp, while month and year only step down the year/month fields of a struct tm-like Fields value whose day may temporarily point beyond the end of the month, and which normalizes like mktime(3) — rolling any excess days over into the following month. As in Git, each month/year pair first normalizes whatever the previous pairs left behind, pairs apply in input order, and repeated units accumulate.
• Everything stays in UTC, as before; the (separate, already-known) local-time-zone question is untouched, and named dates (now, today, yesterday) are unaffected.
• The various() test now uses a fixed now (the baseline's GIT_TEST_DATE_NOW=1000000000): its expected values are computed with jiff's clamping subtraction and would disagree with Git — and with this fix — when the test happens to run near the end of a longer month.
• Error behaviour is preserved: too-large counts still fail with Couldn't parse span from '<unit> <count>', and the historical negative-span failure case is kept.

Why not extend the baseline instead?

The baseline fixture pins GIT_TEST_DATE_NOW=1000000000 (2001-09-09) for all relative dates, which can never produce a month-end rollover. The new months_and_years_roll_over_month_ends_like_git test therefore hard-codes values obtained from Git itself; each one reproduces with TZ=UTC GIT_TEST_DATE_NOW=<now> git rev-parse --since='<input>' (git 2.48.1), as noted in the test. I'm happy to extend the baseline format to support per-entry now values instead, if that's preferred.

Test evidence

The new test fails before the fix and passes after it:

$ git stash push -- gix-date/src/parse/relative.rs   # old implementation, new test
$ cargo test -p gix-date months_and_years
<1772280000 (clamped) vs >1772539200 (Git)
test result: FAILED. 0 passed; 1 failed
$ git stash pop

Full crate test suite:

$ cargo test -p gix-date
test result: ok. 55 passed; 0 failed; 0 ignored (unit + baseline)
test result: ok. 1 passed (doc-tests)

cargo clippy -p gix-date --all-targets is clean. Cross-checked all twelve table rows from #2909 (plus order/accumulation cases) against git rev-parse --since with pinned GIT_TEST_DATE_NOW: gix-date now matches Git exactly on every one.

Disclosure: this PR was prepared with AI assistance (also marked with an Assisted-by: commit trailer); I reviewed the change and verified every reproduction locally against git 2.48.1.