fix: cap the timerange offset with the stability window

[mkoura]

The Plutus "time range" minting tests set the tx validity interval 300 slots past the tip. The ledger has to translate that upper bound to a time for the script, and it can do so only up to its forecast horizon: the end of the first epoch that starts at or after the stability window (3k/f slots) from the tip.

On the leios_fast testnet variant the window is only 240 slots (securityParam 4, activeSlotsCoeff 0.05), so a 300 slot interval reaches past the horizon whenever the tip is 300 to 240 slots before an epoch boundary - 60 of the 800 slots of an epoch - and the submission fails with TimeTranslationPastHorizon. Cap the offset with the window, which is by definition always inside the horizon. Variants where the window is at least 300 slots, which is every other one, are unaffected.

The cap lives in plutus_common.get_timerange_slots_offset, with the 300 slots as TIMERANGE_SLOTS_OFFSET. It builds on the new clusterlib_utils.get_stability_window, which test_ttl_horizon uses too instead of computing 3k/f inline. The window is rounded down, as a caller using it as a limit needs a value that is never above the window the ledger itself uses; every testnet variant divides exactly, so no value changes.