Normalize date-type user field values to Y-m-d on import

[flintfromthebasement]

What

Extends pmproiucsv_normalize_user_field_meta_value() (added in #78 for multi-value fields) to also normalize date-type user fields during import:

• Values already in YYYY-MM-DD pass through unchanged.
• Other parseable formats (7/26/22, 07/26/2022, etc.) are reformatted via strtotime() → Y-m-d.
• Unparseable values (including ambiguous EU 25/01/2026) are stored unchanged so they stay visible and correctable — same philosophy as the existing option-key mapping in this function.

Why

PMPro date user fields render as <input type="date">, which requires stored meta to be exactly YYYY-MM-DD. Anything else silently renders blank on Edit User / profile screens even though the value is in the database — and saving that profile submits the empty input, wiping the stored value.

Real-world case (LBCA migration, 2026-08): 1,275 members imported with m/d/yy join dates via this plugin. The field appeared blank in admin profiles and via [pmpro_member], while CSV export (raw meta) still showed values — a confusing symptom set. Several users' dates were wiped by subsequent profile saves before diagnosis.

Notes

• Core membership date columns (membership_startdate/enddate) already run through strtotime() in pmproiucsv_pmp_import_usermeta() processing; their stricter validation is tracked separately in Validate date format on import — require YYYY-MM-DD, surface error for other formats #76. This PR scopes to custom user field meta only.
• Two-digit years follow PHP's standard pivot (00-69 → 20xx). The importer can't assume future dates are invalid (expiration-style date fields legitimately hold future dates), so no century heuristic is applied.
• Tested against: 7/26/22, 2022-07-26, 07/26/2022, 6/1/68, garbage, 25/01/2026, 0, and non-date field passthrough.

🤖 Generated with Claude Code

[flintfromthebasement]

Ran this through the review council; one Major confirmed and fixed in the follow-up commit:

Calendar-invalid dates no longer silently roll forward. strtotime('2/30/2022') returns 2022-03-02 — a typo'd day silently became a different plausible date, contradicting this PR's own leave-it-correctable philosophy. Now using date_parse() + checkdate(): only calendar-valid absolute dates are reformatted; invalid ones (2/30/2022, 04/31/2026), ISO-shaped-but-invalid (2026-02-30), and relative strings (+1 week) are stored unchanged. Docblock updated too.

On the review's open questions:

• DD/MM ambiguity (01/02/2026 read as US Jan 2): pre-existing limitation shared with the core membership_startdate/enddate path — deferring to Validate date format on import — require YYYY-MM-DD, surface error for other formats #76, where stricter/explicit format validation is already scoped.
• Test matrix (stub harness): 7/26/22→2022-07-26, 07/26/2022→2022-07-26, Feb 3 2021→2021-02-03, ISO passthrough, and all invalid/ambiguous cases unchanged.