Validate calendar evidence before runtime date parsing

Calendar evidence must be validated from its original components, not by successful runtime parsing. This applies whenever OCR/model output or external payloads influence identity, eligibility, or reconciliation: accept only explicit documented formats, round-trip year/month/day components against a UTC calendar constructor, and validate an ISO timestamp's date prefix before parsing the full timestamp. The limit is intentional—unsupported human-readable formats should fail closed or be normalized by an explicit parser rather than delegated to a permissive Date constructor.

Why it matters: JavaScript Date parsing can silently roll impossible dates into real later dates, so a value that never appeared in source evidence can become apparently valid and satisfy downstream coherence checks. Tests should cover the same impossible day in every accepted-looking shape, including date-only, slash/dash variants, textual months, and timestamps.

Evidence/example (2026-09-11): In e3-solutions/theft PR #828 / Linear COR-2741, review reproduced February 30 and a non-leap-day ISO timestamp normalizing into March. The fix restricted string inputs to the repository's documented formats and component-validated the original ISO date prefix; bounded regression tests and two independent exact-diff reviews passed. Source provenance: local PR diff and test execution.