fix: persist custom date filter across syslog page navigation

[somethingwithproof]

Fixes #250.

Root cause

set_shift_span() detected shift_span before validate_store_request_vars() restored session values. Page navigation passes only page=N — no date1/date2 in the request — so shift_span was false. That fell into the span branch, which recalculated dates from predefined_timespan and killed the session date vars, wiping the custom filter on every page turn.

Fix

Two changes to set_shift_span():

1. custom case: save date1/date2 to session (same pattern the existing shift case already uses) so subsequent page navigation can find them.

2. false case (page navigation): check whether custom dates exist in session. If yes, restore them and set custom = true instead of recalculating from predefined_timespan.

The span case (explicit predefined-timespan selection) is unchanged: it still recalculates and kills the session dates as before.

Verification

• Set a custom date range in the syslog viewer
• Navigate to page 2, 3, etc.
• Date filter persists across all page turns
• Selecting a predefined timespan still resets to that span correctly
• Time shifts still work correctly

[Copilot]

Pull request overview

Fixes syslog viewer pagination resetting a custom date range by updating request/session handling in set_shift_span() so custom date1/date2 values can be restored when page navigation requests only include page=N.

Changes:

• Adjusts set_shift_span() span logic to avoid recalculating dates on pagination when a custom range exists in session.
• Restores date1/date2 from session and forces custom=true when navigating pages without explicit date parameters.
• Persists custom date1/date2 into session when the user selects a custom range.

[Copilot]

The span-vs-pagination branching only checks for the presence of the session "_date1" key. If "_date1" exists but "_date2" does not (e.g., older session state, partial cleanup, manual session edits), the code will fall into the pagination restore path and later read an undefined "_date2" index. Consider checking that both session date keys exist here (or treating a missing one as "no custom dates" and recalculating from the predefined timespan).

Suggested change

	if ($shift_span == 'span' || ($shift_span === false && !isset($_SESSION[$session_prefix . '_date1']))) {
	if ($shift_span == 'span' || ($shift_span === false && (!isset($_SESSION[$session_prefix . '_date1']) || !isset($_SESSION[$session_prefix . '_date2'])))) {

[somethingwithproof]

Fixed.

[Copilot]

In the pagination restore branch, the code reads $_SESSION[$session_prefix . '_date1'] and '_date2' unconditionally. If either key is missing, PHP will raise an undefined index notice and date filtering may break. Add an isset() (or equivalent) guard for both keys and fall back to the span calculation / defaults when they are not present.

[somethingwithproof]

Fixed.

[somethingwithproof]

Fixed in fc27fb2 -- outer guard now checks for both _date1 and _date2 so partial session state (only one key present) falls through to the span recalculation instead of entering the pagination-restore path.