Catch-up windows must fit inside resumable provider progress

General lesson: increasing a reconciliation catch-up interval is safe only when progress inside that interval is resumable below every provider bound. If a worker records progress only after one participant's entire interval finishes, widening the interval can create livelock: the participant repeatedly exceeds an event, request, page, or deadline cap, restarts from page one, and never publishes trustworthy coverage. Prefer a smaller temporal slice until page/subwindow progress is durable. This applies to provider-backed analytics and backfills whose absence claims gate metrics or classification. It does not prescribe one universal slice size; choose it from expected density and keep failures fail-closed.

This supports the prior lesson that headline results must remain unavailable when evidence coverage is incomplete: faster catch-up cannot weaken the coverage proof.

Evidence/example (2026-09-16): while reviewing e3-solutions/theft PR #912 for COR-4252, an initial proposal expanded Quo reconciliation from one hour to seven days. Independent review showed each participant gets its receipt only after its full scan, while the adapter enforces 1,000-event, 160-request, pagination, and shared-deadline bounds. The implementation was narrowed to one-day slices, preserving exact-cohort fencing and per-unit receipts while reducing a sparse seven-day backlog from 168 windows to seven. Focused reconciliation/provider tests, lint, and TypeScript checks passed. This is source-level evidence; live provider density and elapsed catch-up time remain to be measured.