Fix individual_eitc reform not responding to parameter changes

[DTrim99]

Summary

Fixes the individual_eitc (Winship) reform which was not responding to parameter changes in the app.

Root cause: The reform checked enabled at creation time, not simulation time. Since structural reforms are created with base parameters before user modifications, setting enabled: true in the app had no effect.

Solution: Restructured the reform to follow modern patterns:

• Check in_effect inside the formula using where() (like GA SB520, NJ budget reforms)
• Renamed enabled → in_effect for consistency
• Added missing takes_up_eitc multiplier
• Changed AGI limit behavior: 0 now means "no limit" instead of "no EITC"

Changes

• policyengine_us/reforms/winship.py - Restructured to check in_effect inside formula
• policyengine_us/parameters/gov/contrib/individual_eitc/in_effect.yaml - New parameter (replaces enabled.yaml)
• policyengine_us/parameters/gov/contrib/individual_eitc/agi_eitc_limit.yaml - Updated description
• policyengine_us/tests/policy/reform/winship.yaml - Updated tests with proper structure

Test plan

• Tests set in_effect: true to verify reform activates
• Tests verify baseline EITC when in_effect: false
• Tests verify AGI limit = 0 means no limit
• Tests verify AGI limit blocks EITC when exceeded

Closes #7779

🤖 Generated with Claude Code

[DTrim99]

Addressed review comments:

• winship.py: Removed baseline EITC code - the in_effect parameter handles defaulting to original behavior
• agi_eitc_limit.yaml: Fixed description to single line format

[PavelMakarchuk]

tests fail

[PavelMakarchuk]

PR Review

Should Address

1. Joint bonus always added regardless of filing status — The phase-out start computation always adds joint_bonus:

   phase_out_start = eitc_params.phase_out.start.calc(child_count) 
       + eitc_params.phase_out.joint_bonus.calc(child_count)

   The original branch approach inherited filing-status-dependent behavior from eitc_phase_out_start. This always adds the joint bonus even for single filers, which may overstate EITC for non-joint filers.

2. Lost eligibility checks — The old branch approach computed EITC through standard intermediary variables that enforced investment income limits, age requirements for childless filers, etc. The new direct computation bypasses that machinery — it only gates on eitc_eligible at the top level but manually recomputes phase-in/phase-out without the additional constraints.

3. uv.lock has a version regression — revision 3→2 and version 1.592.1→1.598.0. Looks like a stale lockfile from an older branch. Should rebase or regenerate.

4. Test Case 5 doesn't actually test the "no limit" logic — The test sets agi_eitc_limit: 0 (meaning no limit) with 100k income, expecting 0 EITC. The comment says "Head with 100k income is past EITC phase-out, so 0." This passes because of the phase-out, not the no-limit behavior. A test with income within the EITC range and agi_eitc_limit: 0 would actually verify the no-limit logic works.

---

To auto-fix issues: /fix-pr 7780

[DTrim99]

Addressed Review Comments

All issues from the review have been fixed:

1. Joint bonus only applies to joint filers ✅

Added is_joint check so joint bonus is conditional on filing status:

is_joint = tax_unit("tax_unit_is_joint", period)
joint_bonus = eitc_params.phase_out.joint_bonus.calc(child_count)
phase_out_start = (
    eitc_params.phase_out.start.calc(child_count) + is_joint * joint_bonus
)

2. Eligibility checks preserved ✅

The reform uses defined_for = "eitc_eligible" which gates on eitc_eligible. This variable includes all baseline EITC eligibility checks:

• eitc_investment_income_eligible - Investment income limit
• eitc_demographic_eligible - Age requirements for childless filers, etc.
• filer_meets_eitc_identification_requirements - SSN requirements
• Separate filer limitation

3. uv.lock regression ✅

Reverted uv.lock - no longer included in PR changes.

4. Test Case 5 now properly tests no-limit logic ✅

Changed income from 100k (which was past phase-out) to 20k (within EITC range). Now the test verifies that agi_eitc_limit: 0 means no limit by expecting the same EITC as Case 3.