Account for nanosecond carry and borrow before rejecting Duration overflow

The checked addition/subtraction functions reject overflow in the seconds component before normalizing nanoseconds. This rejects representable exact results at both ends of the range.

Let MIN/MAX denote the i64 limits and use `(seconds, nanoseconds)` notation:

- `(MIN, 900000000) + (-1, 200000000)` should be `(MIN, 100000000)`.
- `(MAX, 100000000) - (-1, 900000000)` should be `(MAX, 200000000)`.

Both currently hit the early error branch. The saturating wrappers consequently return an endpoint instead of these exact results.

Source evidence at the head of #520:

- [std/time/duration.wave:100](https://github.com/wavefnd/Wave/blob/2ae0a91c57fd76323124c0e4dff552adbfadbe1b/std/time/duration.wave#L100) — `pub fun time_duration_checked_add`
- [std/time/duration.wave:131](https://github.com/wavefnd/Wave/blob/2ae0a91c57fd76323124c0e4dff552adbfadbe1b/std/time/duration.wave#L131) — `pub fun time_duration_checked_sub`

Acceptance:

- [ ] Incorporate carry/borrow into overflow decisions without executing overflowing intermediate signed arithmetic.
- [ ] Cover both examples, reversed addition operands, genuine overflow, and adjacent representable values.
- [ ] Verify the checked and saturating APIs agree whenever the exact normalized result is representable.

Audit status: identified by static source inspection; the scenarios above have not been executed during this audit. The permalink fixes the reviewed revision; this report does not claim the defect was introduced by #520.

Start with std/time/duration.wave at time_duration_checked_add and time_duration_checked_sub, then trace how their checked and saturating APIs normalize seconds and nanoseconds. Add coverage for the two examples, reversed operands, genuine overflow, and adjacent representable values; done means carry/borrow is included safely in overflow decisions and checked and saturating results agree for representable normalized values.

Written by the indexing model from the issue text.