1475 feature rework status2024 demand data rerun generation independently instead of proxying egon2035 and verify hp capacity placeholder

[MoritzSchloesser]

What this does

Replaces the status2024 demand/PV proxying with direct reads, and fixes three defects found
while verifying the resulting heat pump distribution.

Closes #1475 (partially — see Still missing below, which is why this is a draft).

Changes

1. Read status2024 data directly instead of proxying eGon2035

demand_source_scenario() and pv_source_scenario() now resolve status2024 to itself. Real
data is present in egon_peta_heat, egon_map_zensus_district_heating_areas and
egon_power_plants_pv_roof_building.

The demand proxy was not cosmetic: status2024 residential heat demand is ~58 % higher than
eGon2035's (22.0 vs 13.9 TWh), so heat pumps were being sized from the wrong profile.

The PV mapping pointed at "status_quo", a scenario that does not exist in
egon_power_plants_pv_roof_building (it holds only eGon2035 and status2024). The lookup
matched zero rows, so every building fell back to equal weight and the PV weighting had no effect
at all — silently, with no error.

2. Fix double boundary scaling of the status-quo HP target

insert_capacities_status_quo() already reduces the national rural_heat_pump target to the
dataset boundary via population_share() (3.49 % for Schleswig-Holstein).
cascade_per_technology()'s national branch then divided by 16 again as a crude
"1 of 16 federal states" proxy.

	before	after
national target	10,000 MW	10,000 MW
× population_share()	349.42 MW	349.42 MW
÷ 16	21.84 MW	(removed)
distributed to MV grids	21.84 MW	349.42 MW

eGon2035 never hit this: it takes the federal_states branch, which reads a per-state row and
has no such division. The national branch is used only by status scenarios, so the /16
predates them and assumed an unscaled target. Full-Germany runs were unaffected.

3. Fix duplicate building ids in the PV-weighted selection

egon_power_plants_pv_roof_building contains every status2024 row twice (233,700 rows for
116,850 buildings). Those duplicates entered the weights index in
determine_buildings_with_hp_in_mv_grid(), so np.random.choice could draw the same building
twice. Both copies were allocated capacity, and the second was then silently dropped by
drop_duplicates("building_id") in the bulk export — removing that capacity from the grid's
budget with no rescaling.

Measured via temporary instrumentation: pre_dedup_sum = 349.417503 MW (exactly the budget),
then 72 rows / 1.68 MW dropped before the write.

Deduplicating and sorting the PV query result also makes the seeded draw reproducible. The
query has no ORDER BY, so the weights index was built in arbitrary order and --random-seed
did not pin the outcome — repeated runs returned 87 / 90 / 92 buildings for the same grid.

The duplicated rows are a bug in pv_rooftop_to_buildings() (the accumulator is seeded with the
status-quo rows before a loop that appends them again). That is filed separately, since it also
doubles status-quo PV capacity for home_batteries and sanity_checks. The change here is
defensive so the HP path is correct regardless.

4. Fix KeyError when only part of the NEP scenarios are configured

insert_nep_list_powerplants() loads NEP2021 for eGon2035 and NEP2025 for
reGon2037/reGon2045. With only one group configured the other frame stays empty, so the
concatenated result lacks that list's capacity columns. Two places assumed all columns exist, so
a run with [status2024, eGon2035] on a federal-state boundary failed twice in a row:

KeyError: 'c2037_capacity'
KeyError: "['c2037_capacity', 'c2045_capacity'] not in index"

Pre-existing on dev; needs both a partial NEP scenario set and
--dataset-boundary != "Everything" to trigger, which is why CI has not caught it.

5. Let SanityChecks build with no implemented scenario checks

Sanity checks only cover eGon2035 and eGon100RE. With neither configured the tasks tuple was
empty and Dataset raised, breaking DAG construction. Falls back to a no-op that logs which
scenarios ran unchecked.

Verification

status2024 vs eGon2035 in a Schleswig-Holstein run:

	status2024	eGon2035
heat pumps	14,934	103,022
capacity	349.417 MW	1,654.370 MW
mean HP size	23.40 kW	16.06 kW
conservation	100.0000 %	99.9998 %

Checks that hold for both scenarios:

• Capacity conservation — sum(hp_capacity) equals the HeatSupply budget: 349.41800 vs
  349.41750 MW for status2024 (0.0001 % float rounding), 1654.36000 vs 1654.36833 MW for
  eGon2035. Every MV grid reaches its budget.
• Sizing rule — every building gets at least peak_load × (24/18) / 1.7; no undersized buildings
• Units — hp_capacity in MW, peak_load_in_w in W, eTraGo series length 8760
• PV weighting active — PV-owning buildings are over-represented among HP buildings

A review notebook covering these is available on request (not committed — it is analysis, not
pipeline code).

Still missing (why this is a draft)

• Sanity checks for status-quo scenarios. Item 5 only stops their absence from breaking the
  DAG; the checks themselves are unwritten.
• ADRs 0001 / 0002 are referenced by [FEATURE] Rework status2024 demand data: rerun generation independently instead of proxying eGon2035, and verify HP capacity placeholder #1475 but not present in docs/adr/. Either they were
  never committed or they live elsewhere — worth resolving before merge so the references are not
  dangling.

Out of scope

• Phase E — future scenarios treating status2024's per-building assignments as a fixed floor ([FEATURE] Make future-scenario HP distribution treat status2024's assignments as a fixed floor #1477)
• Other exact-string scenario gates across power_plants/, chp/, demandregio/, motorized_individual_travel/
• The pv_rooftop_to_buildings() duplication itself (filed separately)