fix(clim): proratiser la conso de froid au logement pour les dpe générés depuis l'immeuble (#303)

[elliot-redfroggy]

Closes #303

Problème

Pour un DPE appartement généré à partir de l'immeuble (méthodes 10-13, 33, 34, 38-40), calc_clim calcule le besoin et la conso de froid à l'échelle de l'installation (Bfr × surface_clim / SH_immeuble). Ces valeurs n'étaient jamais ramenées au logement : on attribuait au lot la conso de froid de tout l'immeuble, alors que le chauffage et l'ECS sont bien proratisés.

Ex. 2688E0016748T (7 logements, 514,5 m², LICIEL / BBS_Slama) : di.conso_fr = 409,26 (immeuble), ADEME logement = 62,68 = 409,26 × 78,8 / 514,5, Open3CL main = 400,99.

Correctif (legacy)

• engine.js : prorataFroid = Sh_logement / SH_immeuble pour les méthodes générées depuis l'immeuble (1 sinon, et 1 si SH_immeuble ≤ Sh), passé à calc_clim.
• 10_clim.js : le prorata est mémorisé dans donnee_utilisateur.prorata_logement. Les donnee_intermediaire restent à l'échelle de l'installation, comme dans le DPE de référence (di.conso_fr = 409,26).
• conso.js : ret.fr / ret.fr_depensier appliquent prorataFroidLogement(fr). Ça couvre EF, EP, GES, coût et la ligne électricité, et ça se cumule avec la minoration PV.

Référence Tribu : Calcul_installation_froid.cs l.62-64 (Bfr = Bfr_bat × Sh_fr / Sh_total), Calcul_batiment.cs l.1114-1138 (Cfr agrégé à l'immeuble, puis prorata au logement).

Nouvelle archi : ConsoFroidService ne produit que les donnee_intermediaire à l'échelle de l'installation, qui sont déjà correctes. L'agrégation ef_conso n'existe pas encore dans features/, donc il n'y a rien à proratiser pour l'instant. Le prorata devra être appliqué à l'agrégation quand elle sera migrée.

Tests

• 10_clim.spec.js : +2 (prorata mémorisé, défaut 1, di inchangées)
• conso.spec.js : +2 (conso / dépensier / GES proratisés, prorataFroidLogement)
• engine.spec.js : +10 (9 méthodes générées → 0,4 ; map 15 → 1 ; SH ≤ Sh → 1)
• Suite complète : 35 échecs, tous présents sur main avant ce changement, aucun nouveau.

Replay (main vs branche, bug_for_bug_compat)

3 655 DPE avec climatisation (corpus_dpe, ind. à partir d'immeuble 2026, appart. ch. ind./coll. 2025, logement 2025) :

conso_fr modifiée	89 DPE, tous en méthodes 10-13/33/34. 0 hors périmètre
conso_fr à <1 % de l'ADEME (DPE générés)	main 0/89 → branche 75/89
KO→OK	62 (10: 25, 13: 17, 11: 14, 33: 5, 12: 1)
OK→KO	2, des compensations (Tribu 1.4.25.1)

OK→KO :

• 2313E4450644F (DPEWIN, map 33) : conso_fr ADEME 85,8, main 428,9 → branche 85,79 (exact). L'écart d'EP de 7,8 % vient d'un autre poste que le froid compensait.
• 2377E0818271A (map 34) : conso_fr ADEME = 0 (clim non comptée par le logiciel), main 367,9 → branche 8,7. Export incohérent.

[elliot-redfroggy]

Analyse des 2 sorties sur corpus_dpe (2313E4450644F, 2377E0818271A)

Sur main, ces deux DPE passaient parce que la conso de froid de l'immeuble entier compensait un défaut de l'export. Le correctif ne casse rien.

Le prorata est confirmé par Tribu 1.4.25.1. Sur corpus_dpe, 13 DPE générés depuis l'immeuble ont une clim. Pour 11 d'entre eux, le conso_fr ADEME est égal au prorata (ex. 2306E3181364M 37,7 / 37,7, 2413E3009196Y 10,04 / 10,0, 2384E3572248M 410,8 / 408,5). Sur main on était à 10-100 fois plus.

2313E4450644F (DPEWIN 5.1.9, Tribu 1.4.25.1, map 33)

• Avec le correctif, conso_fr = 85,79 pour 85,8 côté ADEME : la valeur est exacte.
• Côté ADEME, la somme des postes ne fait pas le total : ch + ecs + éclairage + fr + aux. ventilation = 2 948 kWh EF, contre conso_5_usages = 3 280,8.
• Si on remplace le froid par la valeur de l'immeuble (428,94 au lieu de 85,8), on obtient 3 291 en EF (écart 0,3 %) et 7 570 en EP pour 7 545,8 (écart 0,3 %).
• Le total 5 usages exporté contient donc le froid non proratisé, alors que le poste froid est proratisé. Le DPE est incohérent avec lui-même.

2377E0818271A (logiciel 3.0.7, Tribu 1.4.25.1, map 34)

• conso_fr = 0 alors qu'une clim de 662,77 m² est décrite.
• conso_totale_auxiliaire (44,1) est inférieur à conso_auxiliaire_ventilation (125,4).
• ep_conso_ecs et ep_conso_ecs_depensier sont inversés (3 829,7 / 2 716,1).
• C'est un export incohérent.

Proposition : retirer ces 2 DPE de corpus_dpe.csv comme exports incohérents, comme dans #310.