Bump the policyengine-us engine lock to 1.819.0 (pin-unlock step 0; blocked on take-up mapping for 4 new programs)

[MaxGhenis]

Step 0 of unblocking the US model pin. Draft on purpose — the decision to build and certify on a new engine is the maintainer's.

Why the pin has been stuck

policyengine.py has pinned policyengine-us==1.764.6 in every bundle through 5.0.3 while PyPI is at 1.819.0. Nobody decided that; it's mechanical: pe.py's certification mirrors the engine a Populace build was built with (compatibility_basis: built_with_model_package, see policyengine.py#475), and this repo's uv.lock has resolved 1.764.6 since 2026-07-06 — so Builds I, J, M, O and P were all produced on 1.764.6 and every certification re-pinned it. The spec already allows policyengine-us>=1.745.0,<2; only the lock was stale.

This PR

uv lock --upgrade-package policyengine-us: 1.764.6 → 1.819.0 (pulls policyengine-core 3.26.11 → 3.31.0). Nothing else in the lock changed.

What CI tells us

Whether the build packages still resolve, import and pass their unit tests against a current engine. It does not run a build.

What comes after (separate, gated)

1. A Populace US build on this engine (the fiscal-refresh driver + release gates; hours on the build machine). The release gates are the place to watch for input-surface drift — engine releases since 1.764.6 may have renamed or removed input variables, which would show up as dropped columns/mass in the build diagnostics.
2. scripts/certify_data_release.py in policyengine.py against that release; generate rewrites the policyengine-us pin automatically when the built-with version moves (the Build M runbook, step 4).
3. A policyengine.py release → sim-api executor → api bundle, via the normal release train.

That chain is what finally ships the Oregon Kids' Credit fixes (pe-us ≥ 1.775.7) and the uprating-freeze fix to policyengine.org.

🤖 Generated with Claude Code

[MaxGhenis]

Step-0 results (2026-08-23, [us]-extra environment on pe-us 1.819.0 / core 3.31.0)

Mandatory CI (no engine installed): 6,399 passed, 1 failed — the failure was the deliberate lock guard test_locked_policyengine_us_pin_guards_the_obbba_window_premise, whose comment prescribes the bump procedure. Followed it:

1. OBBBA window premise re-verified on 1.819.0 — in both deductions_if_itemizing and deductions_if_not_itemizing, overtime_income_deduction and tip_income_deduction are absent at 2024-01-01, present at 2025/2026/2028, absent at 2029-01-01. The guard now pins 1.819.0 (second commit).
2. Real blocker found — the spec engine fails closed at import on this engine:

   SpecValidationError: take_up/programs: mapping is not total over the fresh engine ABI;
   missing=['takes_up_ca_premium_subsidy_if_eligible', 'takes_up_co_premium_assistance_if_eligible',
            'takes_up_nm_premium_assistance_if_eligible', 'takes_up_wic_if_eligible'], extra=[]
   

   policyengine-us added four take-up switches since 1.764.6 (CA/CO/NM premium assistance, WIC). The F0 spec requires the take-up mapping to be total over the engine's ABI, so a build on 1.819.0 cannot start until those four get take-up assumptions declared in take_up/programs. That is a modeling decision (take-up rates), not a mechanical edit, so it is not in this PR.

So this PR is now: lock bump + guard update, blocked on the take-up mapping for the four new programs. Once that lands, the build → certify → release chain in the description applies unchanged.

🤖 Generated with Claude Code