livecheck: add max-age fallback for throttled versions

[dasmfm]

Keep modulo-based throttling as the default, but allow a formula or cask to opt into a time-based fallback via throttle_max_age_days so stale formulas can still be bumped when release cadence is high.

What this changes

• Adds a new optional livecheck DSL setting: throttle_max_age_days.
• Keeps existing throttle behavior unchanged by default (patch % throttle == 0).
• When throttle_max_age_days is set and no throttled version is found, latest_throttled falls back to latest if the formula/cask file has not been updated for at least that many days.
• Uses git history (git log -1 --format=%ct) for the formula/cask source file to determine last update age.

Why this is useful

• throttle prevents noisy frequent bumps for fast-moving projects.
• Some projects release rapidly but may not hit the next modulo boundary for a while.
• throttle_max_age_days provides an opt-in safety valve so entries do not stay stale indefinitely.
• Inspired by opencode in homebrew-core, where strict throttling can make formula updates much less frequent than upstream releases, losing patch versions, after change of release frequency.

Scope

• This PR intentionally only changes livecheck behavior and related unit tests.
• It does not modify bump-formula-pr, bump-cask-pr, or auditor behavior.

Related discussion

A previous proposal explored replacing modulo-based throttle behavior with time-based logic (see #15286).
This PR intentionally takes a different approach:

• it preserves modulo-based throttling as the primary/default behavior;
• it adds an optional fallback (throttle_max_age_days) only for cases where no throttled version is found and the formula/cask has been stale for a configured time.
  So this is additive and opt-in, not a replacement of existing throttle semantics.

---

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests (excluding integration tests) for your changes? Here's an example.
• Have you successfully run brew lgtm (style, typechecking and tests) with your changes locally?

---

• AI was used to generate or assist with generating this PR.

I used Codex 5.3 assistance to help draft and refactor the implementation/tests and PR wording.
I manually reviewed all file changes and verified behavior.

---