Bound INT03 replay calendar to the run window

[hjcud]

What changed

• build the official session schedule from each job's immutable data-requirement window
• stop using the execution policy's much wider applicability envelope as the replay window
• classify pinned-calendar coverage mismatches as one non-retryable REQUIRED_INPUT_UNAVAILABLE outcome
• add regressions for the INT03 2016-2026 policy / January 2024 run mismatch and permanent attempt handling

Why

The newly authorized INT03 Development journey created run 6c7cc267-ab2a-32a6-846d-e80523a3abc5. The run's data is inside the pinned XNYS calendar, but the worker requested the policy's 2016-2026 applicability period. The pinned calendar covers 2024-2026, so the same deterministic CalendarCoverageError was retried five times before the message left the queue.

This change keeps policy applicability validation separate from the concrete replay interval and makes a genuine coverage mismatch terminal on the first attempt.

Closes #82.

Related platform compatibility evidence remains tracked separately in Idea2Strategy/Idea2Strategy#471.

Validation

• focused calendar regressions: 2 passed
• tests/test_orchestrator.py: 22 passed
• non-Docker suite: 1,252 passed, 3 skipped
• Docker suite: 158 passed, 10 skipped
• Ruff: passed
• mypy: passed (74 source files)
• pip-audit: no known vulnerabilities

[hjcud]

Superseded by merged PR #84. Canonical Development policy evidence describes the policy period as the actual evaluation window, so shrinking scheduling to requirement bounds would violate the published policy semantics. PR #84 correctly fails the current incompatible inputs once before RUNNING.