fix: tighten AgreementStartDate CFN pattern + strptime safety (§1.129, §1.130)

[hyunsies]

Summary

Closes §1.129, §1.130 — CFN date pattern + strptime safety.

• Replace weak `^\d{4}-\d{2}-\d{2}$` with `^(19|20)\d{2}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$` on `AgreementStartDate` (main YAML + configurator).
• Mirror same tightening on `AgreementEndDate` in configurator (same class of bug — both date params).
• Wrap `datetime.strptime()` in try/except `ValueError` in 3 places: `is_after_agreement` (main YAML Lambda), `is_within_agreement` (configurator Lambda), backfill `start_time` parsing (configurator backfill Lambda).
• On `ValueError`: log + return False (event treated as out-of-scope). Do NOT raise / DLQ — stack is operator-broken, customer must redeploy, so DLQ spam is noise not signal.

Severity re-scope: CRITICAL → MEDIUM

Phase 16's evidence (5,339 DLQ from `2024-13-01`) came from raw-YAML deploy bypassing the configurator's CFN AllowedPattern. In the real customer path, CFN rejects invalid dates at stack creation, so this is a defense-in-depth fix, not a runtime-severity bug.

Verify-flag results

• (1) Severity re-scoped (see above).
• (2) Kept scope narrow to date params only. MpeId at :18 already has `^mig[a-zA-Z0-9]+$` — not touched.
• (3) On ValueError: log + return (not DLQ). Confirmed rationale in commit.
• (4) No overlap with PR fix: remove dead cross-account code path (H1, Wave 14 Option A) #35's MpeId guard — this PR touches dates only.

Regex validation (tested locally)

Input	Matches
`2024-01-01`	✓ pass
`2024-12-31`	✓ pass
`2024-13-01`	✗ reject (month > 12)
`2024-01-32`	✗ reject (day > 31)
`1899-01-01`	✗ reject (year < 1900)
`2100-01-01`	✗ reject (year > 2099)
`2024-02-30`	✓ pass (still semantically invalid; caught by strptime try/except)

Test plan

• `python3 .github/scripts/sync-check.py` passes
• Regex tested locally with 9 cases
• E2E green on this branch