fix(fix): PG::DatetimeFieldOverflow in Notifications::WorkflowJob#switch_state (WP #65108)

[thykel]

What are you trying to accomplish?

Administrators could enter an arbitrarily large value in the "User actions aggregated within" field under Administration → Emails and notifications → Aggregation. When a value large enough to overflow PostgreSQL's timestamp range was stored (e.g. 9999999999), every subsequent call to Notifications::WorkflowJob crashed with:

PG::DatetimeFieldOverflow: ERROR: timestamp out of range: "677347521-07-22 12:03:56"

This blocked notification delivery for all users on the affected instance.

What approach did you choose and why?

The fix is applied at three layers to be robust against both future bad input and existing bad values already in the database:

1. UI constraint (AggregationSettingsForm): Added max: 3600 (and min: 0) to the number input so the browser enforces the allowed range before a form submission is even made.

2. Server-side contract validation (Settings::UpdateContract): Added a journal_aggregation_time_minutes_range validation that rejects any value outside 0..3600. This is the authoritative guard — it runs regardless of how the setting is written (UI, API, console).

3. Runtime cap in the job (Notifications::WorkflowJob): The wait: lambda now uses [Setting.journal_aggregation_time_minutes.to_i, 3600].min.minutes. This prevents the crash for instances that already have an out-of-range value stored in the database, where the contract fix alone would not help.

The cap of 3600 minutes (1 hour) matches the value explicitly suggested in the bug report and is far below the PostgreSQL timestamp ceiling.

Merge checklist

• Added/updated tests
• Added/updated documentation in Lookbook (patterns, previews, etc)
• Tested major browsers (Chrome, Firefox, Edge, ...)