schedule-catalog parity fixture fails when a recording crosses a schedule's wall-clock occurrence #1102

Problem

The schedule-catalog shared-fixture corpus depends on wall-clock time. Its live schedules have real daily occurrences. If a recording runs across one of them, the reference server's maintenance evaluator fires the schedule. The responses then differ from the reviewed published-PHP expectations and the corpus job fails, whatever the change under test.

Observed failure (first E4 merge group, #1101)

• Run 42464537818, job mysql-execution (existing-php-mysql-matrix, corpus).
• Merge group 60a99eb6 = [M 2a15179f, E4 6754daa8], whose tree differs from M only in scripts/ci/native-qualification-subject.json. The corpus does not read that file.
• Failing assertion at scripts/conformance/server-parity/schedule-catalog-contract.mjs:166, "every response matches the reviewed published PHP responses". The published-PHP recording shows schedule alpha with fires_count: 1, last_fire/last_fired_at set and remaining_actions: 4. Expected is 0, null, null and 5.
• Why: the PUT at fixture line 57 sets alpha to cron 0 4 * * * in America/New_York (tests/Fixtures/ServerParity/schedule-catalog.json:57). On 2026-11-08 (EST, UTC−5) that occurrence is 09:00:00 UTC. The diff was printed at 09:00:00.99Z.
• The same corpus passed on M's own merge group 42457788790 at 07:11Z. Record: Qualify the runner against the published Native 3.3.0 index #1101 comment 6719693612.

Exposure: live, unpaused schedules and their natural occurrences

Any corpus recording that spans one of those instants can fail. The same applies to the Native and embedded targets if their evaluators fire, since every target is compared against the same reviewed expectation.

Constraints

• Schedule specs have no start/end bounds (rust/src/runtime/schedule_spec.rs), so a window cannot be expressed in the spec.
• The expected file is a reviewed published-PHP recording. Changing request bodies means re-recording and re-reviewing it.
• The fixture deliberately exercises cron + timezone updates, interval specs and backfills. A remedy must keep that coverage.

Proposed deterministic remedies (source investigation only)

1. Preferred, no fixture change: guard the recording window. Before recording schedule-catalog, compute this fixture's fixed occurrence set (the instants above, using DST-aware zone offsets for the recording date). If the bounded recording window, e.g. 10 minutes plus margin, intersects one, wait until it has passed. Record the decision in the evidence. This removes the crossing at a bounded cost and changes no reviewed bytes.
2. Alternative: long-period specs. Replace the P1D intervals with a period whose next natural occurrence is decades away. Replace alpha's daily cron with a cron/zone update whose next occurrence cannot fall during CI, after checking that the published PHP parser accepts it. Then re-record and re-review the expected file. This is a larger change because the spec echoes and next-fire normalization in many responses would change.
3. Not recommended: normalizing away fires_count, last_fire or remaining_actions. That would hide real schedule-state regressions.

Acceptance

• A control proves a recording started just before a natural occurrence does not cross it (option 1), or that no natural occurrence can fall within a day of CI (option 2).
• All existing schedule-catalog assertions are unchanged.
• The Native, embedded and published-PHP comparisons still pass on the existing reviewed expectation (option 1), or on a re-reviewed one (option 2).

Owner: Server. Status: source investigation only. No competing PR train is selected while the E4 integration (#1101) is in custody.