Refine IL CHIP premium encoding for Level 1 child-count schedule

[MaxGhenis]

Follow-up from #8086.

Context

The newly-added il_chip_premium encodes All Kids Premium Level 1 with a simple per-child rate + family cap pattern:

• per_child: $15
• family_cap: $40

This gives: 1 child → $15, 2 → $30, 3 → $40, 4+ → $40.

The actual IL HFS schedule for Level 1 is:

• 1 child: $15
• 2 children: $25
• 3 children: $30
• 4 children: $35
• 5+ children: $40

So a 2-child tax unit at Level 1 FPL is encoded $5/mo ($60/yr) too high. Level 2 ($40/child capped at $80) is correct.

Why it didn't block the PR

IL's chip_child_income_limit is -.inf in policyengine_us/parameters/gov/hhs/chip/child/income_limit.yaml, so is_chip_eligible_child always returns False for IL residents in natural microsim — the formula silently returns 0. The issue only surfaces in synthetic test cases that set is_chip_eligible_child: true directly.

Proposed fix

Either:

1. Exact schedule: replace per_child.yaml and family_cap.yaml with a single rate scale keyed on n_chip_children (similar to IN's rate_one_child / rate_two_or_more_children split, but with more brackets). Formula picks the rate for that child count.
2. Piecewise formula: keep per-child + cap, plus an "additional child rate" parameter for the $5 incremental structure: premium = min(per_child + max(n - 1, 0) * extra_per_child, family_cap) — but the IL source pattern doesn't cleanly fit this either (first-child $15, second-child +$10, subsequent +$5 each).

Option 1 is more faithful. Level 2 ($40/child capped at $80 = two-child max) can stay as-is since per_child × cap gives the right answer there.

Related

While we're here, is_chip_eligible returning False for IL (and MI, which also has a separate-CHIP program) is an upstream eligibility gap — IL's All Kids Premium and MI's MIChild are separate-S-CHIP programs, not pure M-CHIP expansions. Filing separately may be worthwhile.