Handle unrepresentable Scheduling booking horizons safely

[jeremi]

What Happened

Scheduling policy validation accepts any nonzero u32 horizonDays. Availability later uses infallible Chrono addition for both exact-time and arrival-window offerings. An operator-authored value such as 4294967295 can therefore panic the availability request task when the computed date is outside Chrono's representable range.

The public availability query span is separately bounded, and callers cannot set the policy horizon. This requires malformed trusted configuration and does not bypass authorization or capacity checks.

Expected Behavior

Availability should never panic for a policy accepted by authoring validation. Use checked date arithmetic with a defined saturation/refusal behavior, or establish and validate a product-level maximum horizon for both scheduling modes.

Reproduction

1. Author an otherwise valid exact-time or arrival-window offering with horizonDays: 4294967295.
2. Start Scheduling and request availability for that offering.
3. Observe Chrono's DateTime + TimeDelta overflowed panic path.

Add focused exact-time and arrival-window regression tests at the accepted upper boundary.

Environment

Found while reviewing PR #1092 at commit 68e3060fb. This is beta hardening for invalid operator configuration rather than a remote-input or ledger-integrity issue.