SOP-MARS-39: período endDate silently blocked ALL práctica filing for 2026-1C-Grado cohort since 2026-08-01 (4-day undetected outage)

período endDate was enforced as an upper bound on a práctica's reported date across FOUR sites (create action, create form, edit action, edit page — the edit page selected the bound independently, not the three the reporting ticket implied). 2026-1C-Grado carried endDate 2026-07-31: every práctica-filing attempt for the ENTIRE grado cohort since 2026-08-01 was refused with a well-formed Spanish validation message -- produced no error-tier row, no digest entry, no page. 4-day full outage on the app's primary action, invisible to every alerting instrument, surfaced only because JTP Miyashiro filed SOP-MARS-39. Fixed same-cycle: ceiling is now today (system date) on all four enforcement points, bae9220 v2.66.5. Class-S self-verified: live version 2.66.5 matches, deployment Ready. Cold brief sent to audit-mars-ca. startDate deliberately RETAINED as lower bound (not part of Elazar's ruling; dropping it would allow backdating into a previous cursada). Second finding: edit path had NO independent future-date guard -- the período end was doing that job by accident; same moved-invariant shape as d5d85d5 (MARS-606) the night before -- removing a bound silently promotes whatever it was incidentally enforcing. Data side (db-mars-cc, separate): 2026-1C-Grado and 2026-2C-Grado-EndodonciaI both extended to endDate 2026-12-18. Coverage limit: deploy + code paths verified, not an actual end-to-end práctica submission against prod. SOP-MARS-39 still OPEN, Miyashiro not yet answered -- reply/close needs adminConsole UI or a scripted server-action call (coder cannot drive it headlessly without one).