Default heating_type to electricity and remove the UNSPECIFIED-gated state heating adapters #9754

Follow-up to #9284 and #9360 (the "Stage 3" cleanup named in the #9360 description), and the separate PR promised in the #9663 review thread.

Proposal

1. Change the heating_type default from UNSPECIFIED to ELECTRICITY.
2. Remove the UNSPECIFIED-gated legacy adapters from the state programs, so every household takes the canonical path (heating_expense, the bill matching the heating type).

Keep UNSPECIFIED as an enum member that callers can send explicitly. The new state LIHEAP PRs send it in tests and expect $0.

Why

• Microsimulation. No dataset stamps heating_type, so every record is UNSPECIFIED. The new state LIHEAP programs have no fuel row for UNSPECIFIED and pay $0 on every record (raised in the Add Kansas LIEAP regular heating assistance #9663 review). An electricity default gives those programs a row to read.
• One code path. Consolidate heating expense inputs under a canonical heating_type #9360 added the adapters as a temporary migration switch. New state programs do not have them, so DC, IL, MA and MI now behave differently from every other state when the fuel is not supplied.

State adapters to remove

Line numbers are on main at 7d2a2d7eee.

The state enum mappings also send UNSPECIFIED to the electricity row (dc_liheap_heating_type.py:41, il_liheap_heating_type.py:29, ma_liheap_heating_type.py:34). Those lines and their documentation need the same pass.

Once the four adapters are gone, heating_expense_person has no reader left and can be removed with a removed changelog fragment.

The default change also switches off three shared gates

These are not state adapters, but they test heating_type == UNSPECIFIED, so they stop firing for every caller who does not send a fuel:

With an electricity default and no other change, a household that sends only heating_cooling_expense loses the SNAP heating and cooling allowance unless it also sends an electricity bill or has_cooling_expense. This PR has to decide what replaces these gates; it cannot change the default alone.

Behavior changes to expect

• Callers sending only legacy inputs. DC, IL and MA LIHEAP cap the payment at heating_expense, which for an electricity household reads pre_subsidy_electricity_expense. A household that sends heating_cooling_expense or heating_expense_person and no electricity bill moves to a $0 cap. The MI credit moves the same way.
• Partner contract fixtures. Under tests/policy/baseline/partners/, 17 files send heating_cooling_expense (98 lines) and none sends the canonical heating_type. LIHEAP and SNAP expectations in those fixtures will move. API partners need notice, and a migration path to heating_type plus the per-fuel bill, before this merges.
• Microsimulation. Programs that only need a fuel row start paying the electricity amount. DC, IL and MA stay at $0 until the per-fuel bills are imputed, because none of the heating expense columns is in the dataset (data-compat note in Atomic inputs: consolidate the heating/utility expense input family (LIHEAP, SNAP SUA, CA utility programs) #9284).

Open decisions

1. What replaces the three shared gates: keep reading heating_cooling_expense without the UNSPECIFIED condition, or remove the legacy read and require the canonical inputs.
2. Whether heating_cooling_expense is removed in this PR or stays as a deprecated input.
3. What DC, IL and MA do with an explicit heating_type: UNSPECIFIED after the adapters go ($0 cap, matching the new states, or the electricity row).
4. Timing of the partner notice relative to the merge.

Tests

• Move the DC, IL, MA and MI legacy-adapter cases to canonical inputs or delete them with the adapters.
• Existing cases that rely on the default must send heating_type explicitly, so their expectations do not depend on the default.