Calibrate CHIP take-up before estimating premium collections

Follow-up from #8099.

## Problem

#8099 tried to replace noisy Line 49 CHIP collection proxies with direct FY2024 M-CHIP premium collection values. A second pass through the official FY2024 CMS CHIP financial management workbook found that direct M-CHIP cost-sharing offset rows are zero for CT, DE, MA, MI, and NY, and M-CHIP 20% sheets do not expose premium offset rows. The large M-CHIP `Gross Premiums Paid` rows appear to be expenditure-side premium-category spending, not household receipts.

That means estimating budget-quality CHIP premium collections needs a different path: aggregate modeled household premiums over a CHIP-enrolled population, not child enrollment counts or CMS Line 49 proxies alone.

## Current model/data state

- `chip_premium` is already tax-unit level and captures key family mechanics:
- CT, MA, and NY use per-child premiums with family caps.
- DE and MI use household/family flat premiums.
- The federal 5 percent family income cost-sharing cap is applied centrally.
- `chip_enrolled` currently depends on `is_chip_eligible` and `takes_up_chip_if_eligible`.
- `takes_up_chip_if_eligible` defaults to `True`, so simulated CHIP enrollment is effectively eligibility-based unless an input overrides it.
- `policyengine-us-data` already maps CPS `NOW_PCHIP` to `reported_has_chip_health_coverage_at_interview`.
- That reported CHIP coverage signal does not appear to be wired into PolicyEngine-US CHIP take-up.
- Medicaid has the closer pattern: US-data anchors take-up to reported Medicaid coverage and state-specific rates, then calibrates against administrative Medicaid enrollment targets.
- The raw CMS Medicaid/CHIP enrollment file in US-data includes `Total CHIP Enrollment` by state, which can serve as a state-level target.

## Proposed approach

1. Add a PolicyEngine-US input for reported CHIP coverage at interview, analogous to existing health coverage inputs such as `has_medicaid_health_coverage_at_interview`.
2. In policyengine-us-data, use CPS `reported_has_chip_health_coverage_at_interview` as a reported-first anchor for `takes_up_chip_if_eligible`.
3. Derive state-specific CHIP take-up rates or post-calibration adjustment from CMS `Total CHIP Enrollment`.
4. Add CHIP enrollment state targets to the calibration/loss matrix, analogous to Medicaid enrollment targets.
5. Once CHIP enrollment/take-up is calibrated, estimate aggregate CHIP premium collections by summing existing `chip_premium` by state.
6. Use those state aggregates to revisit #8099's CT, DE, MA, MI, and NY cost-sharing offset calibration.

## Acceptance criteria

- PolicyEngine-US has an explicit reported CHIP coverage input that US-data can populate from CPS `NOW_PCHIP`.
- US-data persists a CHIP take-up input that prioritizes reported CHIP coverage among eligible people.
- CHIP take-up/enrollment is calibrated, or at least diagnosed, against CMS `Total CHIP Enrollment` by state.
- A report compares, for CT/DE/MA/MI/NY:
- CMS Line 49 proxy values,
- direct CMS M-CHIP cost-sharing offset rows,
- modeled aggregate `chip_premium` after CHIP take-up calibration,
- and #8099 expected ranges.
- The premium collection estimate uses tax-unit `chip_premium`, preserving household premiums and family caps instead of multiplying premium schedules by child counts.

## Notes

This is cross-repo work:

- PolicyEngine-US likely needs the reported CHIP coverage input and possibly CHIP take-up behavior changes.
- policyengine-us-data likely needs the CPS `NOW_PCHIP` take-up anchor and CHIP enrollment calibration target wiring.

The goal is not to reinterpret CMS M-CHIP `Gross Premiums Paid` rows as household collections. Those rows should remain excluded from cost-sharing offset calibration unless an official source confirms otherwise.