Respect user date format for activities, calendar events and core date fields

[anonymoususer72041]

Summary

This PR makes OpenCATS consistently respect the user date format (MM-DD-YY vs DD-MM-YY) across the main UI entry points for dates, while keeping the database storage unchanged (YYYY-MM-DD / YYYY-MM-DD HH:MM:SS).

Concretely:

• Activities (candidates & contacts)

  • Use a shared window.CATSUserDateFormat (MM-DD-YY or DD-MM-YY) for:
    • Editing existing activities (fix for Day/Month mixed up when editing activities if UK locale set #344).
    • Creating new activities via the activity/change status and schedule event modals.
  • On the server side, validate and convert activity dates using a dateFormatFlag derived from $_SESSION['CATS']->isDateDMY(), before converting to YYYY-MM-DD HH:MM:SS.

• Calendar events

  • Use the user date format when:
    • Rendering DateInput fields for dateAdd and dateEdit.
    • Populating those fields via SetDateInputDate(...) in CalendarUI.js.
  • Parse and validate dateAdd/dateEdit using the same user date format flag in CalendarUI.php, then convert to YYYY-MM-DD for storage.

• Candidate availability (dateAvailable)

  • Render dateAvailable using the user date format on add/edit.
  • On submit, validate against the user date format and convert to YYYY-MM-DD before saving.

• Job order start date (startDate)

  • Render startDate using the user date format on add/edit.
  • On submit, validate against the user date format and convert to YYYY-MM-DD before saving.

• Extra fields of type “Date”

  • Introduce a helper that determines whether the user/site uses DD-MM-YY or MM-DD-YY, working both for logged-in users and the careers portal.
  • Render date extra fields using DateInput(..., userDateFormat, ...).
  • When editing:
    • Convert the stored canonical value to the user date format for display.
    • Validate the posted value against the user date format.
    • Convert back to a canonical MM-DD-YY representation for storage in the extra field value.

Across all these changes:

• The user-facing date format is now consistent with the user/site setting.
• The database storage format remains unchanged (YYYY-MM-DD / YYYY-MM-DD HH:MM:SS), and only the parsing/validation layer was updated.

Motivation

Previously, OpenCATS assumed MM-DD-YY in several places in the UI and server-side validation, regardless of the user’s configured date format. This led to a few concrete problems:

• Bug in activity editing (Day/Month mixed up when editing activities if UK locale set #344):
  When the user date format was set to DD-MM-YYYY, existing activity dates were still parsed as MM-DD-YY. As a result, day and month were swapped when editing (e.g. 04-08-25 intended as 4 August became 8 April when saved).

• Inconsistent UX when entering dates:
  Some forms always rendered DateInput(..., 'MM-DD-YY', ...) even when the rest of the UI (and the user’s expectation) used DD-MM-YY. This made it easy to enter a “valid-looking” date that was later misinterpreted on the server.

• Risk of silently wrong dates in the database:
  Because the database expects YYYY-MM-DD, but the conversion step assumed MM-DD-YY, users with DD-MM-YY could end up storing logically incorrect dates (day/month swapped) without any error.

This PR addresses these issues by:

• Using a single source of truth for the user date format (isDateDMY() / site preference for unauthenticated users).
• Passing that format down into all relevant DateInput/DateInputForDOM/SetDateInputDate calls.
• Validating and converting user input according to that format before turning it into YYYY-MM-DD / YYYY-MM-DD HH:MM:SS for storage.

The goal is to make date handling predictable and safe for both MM-DD-YY and DD-MM-YY users, without changing the existing database schema or storage format.

[anonymoususer72041]

About the new Codacy warnings:

• The static DateUtility::… calls follow the same pattern as other static utility usages (e.g. FileUtility) that already exist in many places in the OpenCATS codebase. The broader topic is tracked in issue Refactor static utility usages (FileUtility, DateUtility, …) to avoid StaticAccess issues #682, which proposes a gradual refactor of these static helper usages.
• The direct $_SESSION['CATS'] access in ExtraFields::_isDateDMY() also follows an existing pattern: ExtraFields already relied on $_SESSION['CATS'] and site preferences to determine the date format before this PR. Cleaning this up properly would require a larger refactor of how ExtraFields gets its context.

To keep the scope manageable, this PR focuses on fixing the user date format handling (incl. #344) without pulling that wider refactor in. I’d prefer to address the StaticAccess / super-global concerns in dedicated follow-up work (see issue #682), rather than mixing them into this bugfix.