scientific(coverage): make execution consume validation-owner window cardinality #751

Finding

#750 moved the declared rolling-origin window cardinality into CoverageCalibrationDesign::tepp_nominal_95_v1() and bound it into the prospective design fingerprint. The execution owner still keeps an independent EXPECTED_ROLLING_ORIGIN_WINDOW_COUNT: usize = 5 in analysis_engine::coverage_calibration_execution and uses that copied literal for cutoff-shape validation, vector capacity, final window-count validation, and the regression assertion.

The current values agree, so today's numerical result is unchanged. The problem is ownership: a future validation-design revision can change the owner-issued cardinality/fingerprint while the execution path continues to construct and validate a caller-local count. That would either reject the owner design for the wrong reason or, if surrounding geometry also changed, execute a different within-DGP estimand than the fingerprinted design. This is exactly the copied-contract drift #750 was intended to remove.

Required repair

• remove the analysis-local rolling-origin window-count literal;
• make coverage_calibration_execution read the count from CoverageCalibrationDesign::tepp_nominal_95_v1().declared_rolling_origin_window_count() for cutoff geometry, allocation, final validation, and regression evidence;
• keep actual partition construction in analysis_engine; do not move split/cutoff arithmetic into validation_core;
• preserve FIRST_TRAINING_EVENT_INDEX, simulation config/seed schedule, equal-window aggregation, interval arithmetic, percentile/MCSE methods, 10,000 attempted-DGP count, and undefined numerical-failure acceptability;
• add an owner-binding regression contract so future cardinality drift fails before scientific acceptance;
• currentize the stale schema-v6 evidence arithmetic rustdoc to schema v9 while touching the same lane-local owner path;
• do not claim this repair executes the 10,000-DGP study or closes scientific(selection): add leakage-safe rolling-origin K validation #680.

Boundary

validation_core owns the prospective estimand cardinality; analysis_engine owns how the five current windows are constructed from the scenario and canonical rolling-origin admission. The fix is dependency direction, not a second splitter or a new acceptance criterion.

Refs #639 #680 #733 #741 #750.