Audit stale health parameters and rating-area data exposed through metadata/API

## Context
While reviewing health model cleanup candidates, a few objects appear to be unconsumed by current PolicyEngine-US formulas or data generation, but some are still exposed through metadata/API seed paths. We should audit them before deleting or renaming anything.

## Candidates

### Old IRS PTC parameter path
- `gov.irs.credits.premium_tax_credit.eligibility`
- `gov.irs.credits.premium_tax_credit.phase_out.starting_rate`
- `gov.irs.credits.premium_tax_credit.phase_out.ending_rate`

Current ACA formulas appear to use `gov.aca.required_contribution_percentage.*` and `gov.aca.ptc_income_eligibility` instead. Local searches did not find formula/data consumers for the old IRS path. However, `policyengine-api-v2-alpha` testing seeds still whitelist `gov.irs.credits.premium_tax_credit`, so this may be part of an API metadata contract.

### ACA enrollment/spending state parameters
- `gov.aca.enrollment.state`
- `gov.aca.spending.state`

These are exposed in generated app metadata, but local searches did not find current formula/data consumers. We should decide whether these are intended calibration/reference targets, public API metadata, or stale parameters.

### Medicaid geography table / hidden input follow-up
- `policyengine_us/parameters/gov/hhs/medicaid/geography/second_lowest_silver_plan_cost.csv`
- `medicaid_rating_area`

`second_lowest_silver_plan_cost` is imported but did not appear to be used by current formulas. `medicaid_rating_area` is exposed/seeded externally but appears to have no current model consumers. These may be old ACA/Medicaid geography artifacts and should be audited before cleanup.

## Suggested resolution
1. Confirm whether any API partners depend on these names through metadata, reforms, or explicit inputs.
2. If no consumers exist, remove or deprecate them with a changelog entry.
3. If they are API contracts, mark them clearly as deprecated/compatibility-only and migrate consumers to the active ACA parameter path.
4. Consider adding a lightweight stale-parameter check that distinguishes internal formula usage from public API exposure.