Ralph Loop: Recent Replay Coverage

PRD focus: replay evaluation quality.

Problem: research/latest_state.json showed a split signal. Recent source rows were healthy (recent_source_eventful_metadata_rows=40/40, recent_source_pairable_rows=22), but replay pair metadata coverage stayed very low (pair_eventful_metadata_rows=28/772). That made the confidence gate fail for the right reason, but the handoff did not explicitly show that the weakness came from legacy replay mix rather than a current eventful-ingestion failure.

Change: - Added recent-window replay metrics to research.prepare_replay.summarize_replay_rows. - Replay rows now carry _next_run_id so the recent replay slice can require both sides of a pair to come from the recent run window. - research/continuous_loop.py now emits and persists: recent_replay_rows, recent_replay_share, recent_pair_eventful_metadata_rows, recent_pair_eventful_metadata_share, recent_large_move_pair_eventful_metadata_rows, recent_large_move_pair_eventful_metadata_share.

Why this helps: - Ralph can now distinguish “legacy-heavy replay backlog” from “current scans are still missing eventful metadata or revisits”. - This keeps the confidence gate strict without making operators reverse-engineer the bottleneck from separate source-profile counters.

Validation: - PYTHONPATH=. pytest -q tests/test_prepare_replay.py tests/test_continuous_loop.py tests/test_research_search.py - Result: 30 passed in 0.07s