Row caps can split intervention pairs and make smoke-run metrics undefined

Summary

load_items(max_rows_per_dataset=...) truncates raw JSONL rows before intervention pairing is considered. Intervention datasets are paired by id: each instance needs both an unperturbed (X=0) and perturbed (X=1) row for the causal effect and g-mean metric.

A row-level cap can therefore keep only one side of a pair. This is especially easy to hit in smoke runs such as --max-rows-per-dataset 1, where the scaffold loads one intervention row, later warns that the instance is missing an arm, and produces undefined (NaN) intervention metrics.

The option looks like a harmless runtime cap, but for intervention datasets it can change the validity of the evaluation rather than simply reduce its size.

Expected behavior

For intervention datasets, max_rows_per_dataset should cap complete instance pairs rather than arbitrary rows. If the cap is smaller than a full pair, the scaffold should still keep the complete selected instance or otherwise fail clearly instead of silently constructing a one-arm evaluation.

Non-intervention datasets can keep ordinary row-level truncation.

Suggested fix

When an intervention dataset is capped, select instance IDs in stable input order and retain all rows for the selected IDs, with the cap interpreted as a maximum number of source rows while never splitting a selected pair. Add regression coverage showing a one-row cap still preserves both arms of the first intervention instance.

Start at the load_items function and trace how --max-rows-per-dataset is applied to intervention datasets and paired by id. Add regression coverage for a one-row cap that retains both arms of the first intervention instance, while preserving row-level truncation for non-intervention datasets.