Migrate Connecticut county geography to Census planning regions (FY2026 FMR gap)

## Problem

PolicyEngine's `County` enum uses Connecticut's **8 legacy counties** (FIPS `09001`–`09015`). Connecticut abolished county government in 1960, and in 2022 the Census Bureau approved **9 planning regions** (Councils of Governments) as the official county-equivalents, with new FIPS codes `09110`–`09190`. HUD adopted the planning regions in its **FY2026** Fair Market Rents file (bundled in #8804).

## Current behavior (stopgap in place)

As of #8804, `hud_fair_market_rent` falls back to the most recent earlier bundled year when a `(county, bedroom)` row is missing from the queried fiscal year — so a legacy CT county at period 2026 uses its **FY2025** rents instead of returning 0. This avoids the zero-FMR bug, but Connecticut runs on stale prior-year rents rather than the actual FY2026 planning-region values.

## Fix

Migrate the model's county geography to Connecticut's planning regions so CT uses real FY2026 (and later) data:
- `County` enum (`variables/household/demographic/geographic/county/county_enum.py`)
- the dataset's CT county assignment (policyengine-us-data)
- any county-keyed parameters/data that assume legacy CT counties

The planning-region boundaries do not map 1:1 to the legacy counties (they are built from towns that cross old county lines), so the migration needs a town/population-based crosswalk, not a simple rename.

## Context

Surfaced by #8801 / #8804 (year-accurate HUD FMR data). The #8804 fallback is a stopgap; this issue tracks the real geography migration.

Start with variables/household/demographic/geographic/county/county_enum.py and inspect the Connecticut county assignment in policyengine-us-data. Inventory county-keyed parameters and data affected by the change, using the town/population crosswalk requirement as the guide. Done means CT uses planning-region FIPS codes and the FY2026 HUD values without breaking dependent county data.

Written by the indexing model from the issue text.