[FEATURE] Rework status2024 demand data: rerun generation independently instead of proxying eGon2035, and verify HP capacity placeholder

[MoritzSchloesser]

Background

status2024 (the status-quo scenario) currently gets its demand data (egon_peta_heat, CTS heat demand share/profile, DH-exclusion mapping) by proxying live reads to eGon2035 at query time, via demand_source_scenario()/pv_source_scenario() mappings configured in datasets.yml. PV rooftop weighting reads the pre-existing status_quo rows directly (unaffected by this issue).

This was an intentional interim step — see ADR-0002 (docs/adr/0002-rerun-demand-generation-for-status2024-instead-of-proxying.md) — chosen because getting the HP distribution running took priority over building the "real" data path. It's now superseded by a design decision made once the broader multi-scenario pipeline shape (status2024, eGon2035, reGon2037, reGon2045, each task iterating all configured scenarios) became clear.

What needs to change

1. Replace the demand proxy with an independent rerun.

   Rather than status2024 reading eGon2035's rows live via demand_source_scenario(), rerun the demand-generation tasks a second time with status2024 as their own target scenario, producing independent output rows in egon_peta_heat, egon_cts_heat_demand_building_share, egon_etrago_heat_cts, egon_map_zensus_district_heating_areas.

   • Rerun was chosen over copying eGon2035's finished rows so that status2024-specific input data can be substituted later without unwinding a separate copy step.
   • Known consequence to watch for: status2024 and eGon2035 demand data will only match because the generation logic is currently identical for both — any scenario-dependent behavior already latent in that logic (e.g. weather year, building stock assumptions) will surface as a real divergence once this changes, rather than being silently proxied over. Treat that as a signal to investigate, not a bug in the rework itself.
   • Once this lands, demand_source_scenario() / pv_source_scenario() (scenario_parameters/__init__.py) and the heat_pumps_status_quo mapping block in datasets.yml can likely be removed for the demand side (PV mapping stays).

2. Verify the placeholder national HP capacity.

   scenario_capacities.py: 2e6 * 5e-3 = 10,000 MW rural heat pump capacity, and the reused status2023 small_storages figure. Both are marked TODO: VERIFY in code. Per ADR-0001 (docs/adr/0001-defer-hp-capacity-verification-to-full-pipeline-run.md), this was deliberately deferred and must happen before the full pipeline run, not before this issue is considered resolvable — but it shouldn't be forgotten once that point arrives.

Out of scope (tracked separately)

• Phase E: making future scenarios (eGon2035, reGon2037, reGon2045) treat status2024's per-building HP assignments as a fixed floor and only distributing additional capacity on top. Not yet implemented; needs its own scoping once this issue's output exists.
• The various other exact-string scenario-name gates across power_plants/, chp/, demandregio/, motorized_individual_travel/ etc. that would break on status2024 in a full pipeline run. Explicitly out of scope for HP-distribution work.

References

• ADR-0001 — defer HP capacity verification to full pipeline run
• ADR-0002 — rerun demand-generation for status2024 instead of proxying
• Commit 1e8b27fd9 — interim proxy implementation this issue supersedes