fix(datepicker): sync hidden alt field on manual date entry

[faisalahammad]

Description

Fixes #2448

Restores the datepicker hidden alt-field contract from #2884: the hidden field that gets submitted should be the authoritative, unambiguous m/d/Y value regardless of how the date was entered (calendar picker or manual typing).

Prior to this fix, the keyup handler in bind_datepicker only cleared the alt field on unparseable input. A user manually typing a valid date into the visible site-format field left the hidden field stale or untouched, so the stored meta could be an older m/d/Y entry or an empty value, and the front-end parsed it under PHP's US m/d/Y assumption regardless of the configured date_format, causing mis-rendered restriction dates.

After: on a valid parse the handler writes $.datepicker.formatDate(altFormat, date) into the hidden alt field. Existing clear-on-invalid behavior is preserved. Picker selection path is unchanged.

} ).on( "keyup", function() {
    var date;
    try {
        date = $.datepicker.parseDate( format, this.value );
    } catch ( e ) { }

    if ( !altField.length || !/^#[A-Za-z0-9\-_]+$/.test( altField ) ) {
        return;
    }

    if ( date ) {
        $( altField ).val( $.datepicker.formatDate( altFormat || format, date ) );
    } else {
        $( altField ).val( "" );
    }
} );

How has this been tested?

• Manual repro of issue Correctly parse the date saved in Course Options > Restrictions > Enrollment Start Date based on WordPress Dashboard > Settings > General > Date Format. #2448 with WP date_format set to d/m/Y: typed 06/01/2023 (meaning Jan 6) into the course Enrollment Start Date field, saved, confirmed front-end does not show "Enrollment in this course opens on..." for a past date.
• Calendar picker regression: picked Jan 6 via the picker under d/m/Y, confirmed round-trip is correct (idempotent with keyup sync).
• Field clear: cleared the typed date, confirmed alt field is cleared (no stale data).
• Editable date literals (used by bind_editables datetime branch) and the reporting/analytics template date inputs have no data-alt-field, so the early-return branch makes the new logic a no-op there.

Local env: WordPress 6.x, LifterLMS trunk-aligned dev branch. JS lint (npm run lint:js) does not currently cover assets/js/private/, so no automated JS style run is possible against this file in this environment.

Screenshots

N/A - admin UI behavior change is not visually distinct.

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

• This PR requires and contains at least one changelog file. See .changelogs/fix-enrollment-date-manual-entry-parse.yml.
• My code has been tested.
• My code passes all existing automated tests.
• My code follows the LifterLMS Coding & Documentation Standards.