Verification/redetermination churn flag surface (option 2 of #767, generalized)

Split from #767 (design comment there has the full reasoning).

#767's option 2 proposed stored passes_immigration_eligibility_check_{program} flags. For immigration eligibility the stored-verdict form is wrong — the engine recomputes eligibility from immigration_status_str under any law vintage, and a baked verdict would freeze one vintage into the artifact and stop reforms from toggling. That part is resolved by #767's status imputation.

What survives, and generalizes: a person-level verification/documentation propensity surface — whether a person would successfully document status (or income, or work hours) at an eligibility check or redetermination. That is a data attribute the law cannot derive, exactly like takes_up_*_if_eligible, and it is the mechanism for modeling:

• H.R.1's shortened Medicaid redetermination cycles and verification burdens (coverage loss among the still-eligible);
• SAVE-style immigration-status verification churn;
• work-requirement documentation failures.

Shape: data-seeded boolean/propensity person columns (e.g. fails_program_redetermination_if_checked), consumed by engine variables the way enrollment formulas consume take-up flags today, seeded from measured churn evidence (e.g. unwinding-era procedural-disenrollment rates by state).

Sequencing: needs engine-side consumer variables first — file the policyengine-us counterpart when a churn/verification policy is actually being encoded, then add the microcosm stage with cited seeding targets. Parking this issue so the design intent from #767 is not lost.

Read the full reasoning in #767 first, then identify the engine-side consumer variables in the policyengine-us counterpart before making changes here. The issue says the microcosm stage should follow policy encoding and include cited seeding targets; completion therefore depends on that upstream policy work and measured churn evidence.