INT03: bound the replay calendar to the run window and terminate coverage mismatches once

[hjcud]

Production reproduction

After Development release 31302328826, authorized INT03 run 6c7cc267-ab2a-32a6-846d-e80523a3abc5 proved the #255/#257 producer fixes are active, then failed before simulation.

CloudWatch first traceback:

BacktestOrchestrator._schedule(job.execution_policy)
  -> PinnedSessionCalendar.session_schedule
CalendarCoverageError: 2016-07-01 is outside the pinned XNYS coverage
2024-01-01..2026-12-31 (xnys-2024-2026:1.0.0)

The locked run evaluation window and market manifest are 2024-01-01..2024-02-01, which are inside the pinned calendar. The execution policy's periodStart/periodEnd are 2016-07-01..2026-07-01. The orchestrator currently builds the entire calendar schedule from policy bounds before it reads the run's one-month data.

Attempts 1-5 each ended HANDLER_ERROR:CalendarCoverageError / RETRY_RELEASED; the public run remains QUEUED with no top-level failure code. Worker restart_total remained 0. No second run, redrive, DLQ action, DB write, or worker change was performed.

Required regression and boundary decision

1. Add a failing production-path test with the exact policy bounds, evaluation bounds, and January 2024 manifest shape.
2. Decide and encode whether policy bounds are an applicability envelope or the actual replay window. Do not silently widen a calendar or rewrite an immutable policy.
3. Ensure schedule construction, manifest-window validation, and data availability all use one documented bounded window.
4. Classify deterministic CalendarCoverageError as one terminal, non-retryable result rather than five handler retries.
5. Run the exact AWS fixture through the next boundaries too: legacy dataset hash, MARKET_BARS catalog kind, embedded market-bars/1, and policy market-bars-v2 are already known to differ and must be resolved coherently before another Development journey.

Root coordination issue: Idea2Strategy/Idea2Strategy#471.

[kcrmin]

독립 재현 하나를 근거로 붙입니다. 다른 manifest·다른 평가 구간인데 같은 지점에서 같은 실패가 났으므로,
정책 경계가 원인이라는 이 이슈의 진단을 뒷받침합니다.

kcrmin 리허설 계정으로 API 전 과정을 밟았습니다(계정 f61cc348, 전략 b1f67aac).

전략 생성 → 문서 저장 → 검증          VALID (findings: BACKTEST_FEATURE_REQUIRED feature:RSI_14)
릴리스                                 201  botId=c03d326e-919d-3408-b586-3f707683b4d8
run                                    2b6ef43f-0606-346b-acdb-b9b59c3c088b   lane=BASIC

핀된 것	값
run 평가 구간	2024-01-01 ~ 2025-01-01 (그쪽 재현은 2024-01-01~2024-02-01)
시장 manifest	1bb84907-1fb0-43bc-9fed-68850959458c RAW 30m 2024-01-01~2025-01-01, market-bars/1
지표 materialization	d21f0a0e-6ee4-5796-b1fe-222331ac9386 30m 2016-01-01 ~ 2026-07-30
실행 정책	development-official-backtest-2026-q3-v1

CalendarCoverageError: 2016-07-01 is outside the pinned XNYS coverage
  2024-01-01..2026-12-31 (xnys-2024-2026:1.0.0)
  sessions.py:311 _require_covered  ←  sessions.py:303 _range  ←  sessions.py:289 session_schedule
attempts=3, 전부 HANDLER_ERROR:CalendarCoverageError / RETRY_RELEASED, run.status 는 QUEUED 유지

한 달 구간이든 1년 구간이든 동일하게 2016-07-01 을 묻습니다. 즉 run 창의 길이와 무관하고, 이
이슈가 지적한 대로 정책 경계에서 스케줄이 만들어집니다.

제 쪽에서 확인해 드릴 수 있는 것

#82 5번과 루트 #471 이 예고한 다음 경계 중 schema 이름 불일치는 제 리허설 입력에서도 재현됩니다 —
제가 고른 manifest 도 market-bars/1 이고 정책은 market-bars-v2 를 선언합니다. 즉 달력을 통과하면
그다음에서 걸릴 가능성이 높습니다.

정책 경계를 "적용 가능 범위(envelope)" 로 볼지 "실제 replay 창" 으로 볼지는 정책 산출물
(proposals/development-runtime-policy/artifacts/policy-seed.sql) 이 제 소유이므로, 그 결정이
정책 쪽 변경을 요구한다면 제가 맡겠습니다. 결정만 알려 주십시오 — 정책을 조용히 다시 쓰지는 않습니다.

기존 run 은 전부 보존했고 DLQ·재실행·DB 쓰기·워커 조작은 하지 않았습니다.

[hjcud]

Closed as superseded by #83 / merged PR #84. The applicability-envelope hypothesis is rejected by the Development policy artifact, which explicitly defines 2016-07-01 through 2026-07-01 as the evaluation period. The correct next action is to publish mutually compatible immutable policy, manifest/schema, and calendar inputs; root coordination remains in Idea2Strategy/Idea2Strategy#471.