enhanced_cps exporter calls renamed-away load_enhanced_cps_person_frame; shipped feed lacks social_security_retirement

export_enhanced_cps_source (policyengine_uk_data/datasets/enhanced_cps.py:469) calls policybench.load_enhanced_cps_person_frame(), which no longer exists — the function was renamed to load_certified_us_person_frame. The exporter fails on invocation, so the shipped feed enhanced_cps_source_2025.csv cannot be regenerated from the current code path.

Two consequences worth noting together:

1. The committed feed is stale in a way that matters: it derives from the enhanced_cps_2024 vintage, whose social_security_retirement is zero for all 58,848 persons. Building the transfer dataset from it produces a UK file with state pension ≡ £0, which cascades into pension credit (+952% vs the native enhanced FRS) and household benefits (−73%).
2. Re-exporting via load_certified_us_person_frame against the current certified bundle restores the retirement pillar (£1,150.8bn US-side; UK state pension £0 → £91.5bn) and yields 63,128 households vs the old feed's 28,532.

Suggested fix: update the call to load_certified_us_person_frame, regenerate the feed, and consider a build-time guard that fails when a first-class income pillar (e.g. social security retirement) sums to zero in the export.

Found while benchmarking the transfer dataset against the native enhanced FRS; full diagnosis is in that experiment's logs (state-pension cascade root cause, 2026-07-05).

Start at policyengine_uk_data/datasets/enhanced_cps.py:469 and inspect export_enhanced_cps_source together with the current certified bundle loader. Run the exporter using the loader named in the issue, then regenerate enhanced_cps_source_2025.csv and verify that social_security_retirement is nonzero and the household count reflects the current export. Consider the described build-time zero-pillar check if the repository has an appropriate validation path.