fix(pont-thermique): reprendre la ligne PT du DPE si seul le dormant diffère (#296)

[elliot-redfroggy]

Contexte

Issue #296 : sur les DPE DPEWIN 3.1.x / 5.1.x (moteur 3cl_tribu_1.4.25.1, méthodes 26/31-34), la menuiserie exporte largeur_dormant = 5 alors que le pont thermique « menuiserie / mur » exporte le tv_pont_thermique_id de la ligne « dormant 10 », avec le k qui va avec. Open3CL recalcule la ligne « dormant 5 », ce qui donne des deperdition_pont_thermique trop fortes (ex. 2375E2293948T : 1 182 ADEME contre 1 407 O3CL).

Avis de l'expert (Olivier) : normativement, c'est à SORTIR (§3.4.5, largeur du dormant « arrondie à la valeur la plus proche » : la ligne recalculée est la bonne). Un redressement en bug_for_bug_compat reste « défendable comme redressement tracé ». On applique la même politique que pour #292, #293 et #294 (PR #304, #305, #306).

Règle (uniquement en bug_for_bug_compat)

Pour un pont thermique menuiserie / mur en valeur forfaitaire, on reprend la ligne tv_pont_thermique_id exportée par le DPE à la place de la ligne recalculée si toutes ces conditions sont réunies :

• la ligne exportée existe et a le même type de liaison ;
• elle ne diffère de la ligne recalculée que par largeur_dormant (même isolation_mur, même type de pose, même presence_retour_isolation, et une largeur de dormant renseignée mais différente) ;
• son k est égal au k exporté (pont_thermique.donnee_intermediaire.k).

Dans tous les autres cas, et toujours hors bug_for_bug_compat, le comportement normatif ne change pas.

Implémentation

• Legacy (src/3.4_pont_thermique.js) : nouvelle fonction exportée ligneDpeSiSeulDormantDiffere(row, tv_id_dpe, pt_di), appelée dans tv_k après la recherche de la ligne, et seulement pour menuiserie / mur en b4b. Le tv_pont_thermique_id du DPE est lu avant d'être écrasé.
• Nouvelle archi :
  • PontThermiqueTvStore : ajout de getById et de getForMenuiserie (ligne complète). getKForMenuiserie s'appuie désormais sur getForMenuiserie, sans changement de comportement.
  • DeperditionPontThermiqueService : la même règle est appliquée dans pontThermiqueMenuiserieMur (méthode ligneDpeSiSeulDormantDiffere), à partir d'un kExporte passé en paramètre.
  • DeperditionEnveloppeService transmet le pt.donnee_intermediaire?.k exporté.
  • EngineService.#removeComputedData conserve uniquement le k exporté des ponts thermiques (au lieu de supprimer toute la donnee_intermediaire). Le reste est recalculé comme avant.
  • Vérifié sur les 3 exemples de l'issue (dp_PT nouvelle archi, b4b) : 1 400 → 1 172 (ADEME 1 182), 1 185 → 1 037 (ADEME 1 049), 384 → 307,3 (ADEME 307,3). Les petits écarts restants viennent d'autres PT.

Tests

• 43 tests ajoutés (la suite passe de 2 316 à 2 359) :
  • legacy : cas nominal, hors b4b, k différent, autre liaison, plus chacune des conditions de garde ;
  • nouvelle archi : service (pilotage de bug_for_bug_compat par vi.hoisted + vi.mock), store (getById, getForMenuiserie), EngineService et DeperditionEnveloppeService.
• 2 tests existants de 3.4_pont_thermique.spec.js ont été adaptés : en b4b, tv() reçoit maintenant un 3ᵉ appel de vérification, donc l'assertion porte sur le 2ᵉ appel.
• Couverture : 100 % sur src/3.4_pont_thermique.js, pontThermiqueTv.store.js et engine.service.js.
• Suite complète : 35 échecs préexistants sur main, les mêmes 35 sur la branche (12 fichiers identiques), donc aucune régression.

Mesure corpus (main vs branche, b4b, seuil 5 %)

Le scan de corpus_immeuble + corpus_autres (~90 k DPE) trouve 70 492 DPE avec au moins un PT menuiserie / mur forfaitaire. Parmi eux, 4 760 DPE ont un PT dont la ligne exportée a une largeur de dormant différente de celle de la menuiserie et un k exporté égal à celui de cette ligne.

Périmètre	DPE	Modifiés	dp_PT OK (≤ 5 %)	dp_PT exact (≤ 0,01 %)	Valides KO→OK	Valides OK→KO
Concernés	4 760	2 373	2 473 → 4 459 (+2 006 / −20)	2 178 → 4 018	80	63
Contrôle hors périmètre	700	0	676 → 676	666 → 666	0	0

Détail sur les 4 760 DPE concernés : deperdition_enveloppe OK 4 650 → 4 693 ; conso_ch 3 225 → 3 280 ; ges 2 505 → 2 565.

Analyse des 63 OK→KO et des 85 dp_PT dégradés (k par PT rejoués sur les deux versions) :

• dans 100 % des cas, les k des PT menuiserie / mur se rapprochent des k exportés par ADEME. Il n'y a aucun cas où un k s'éloigne ;
• 48 des 63 OK→KO ont un dp_PT à ±0,5 % d'ADEME après correction (contre 7 à 52 % d'écart sur main). Ils n'étaient donc OK sur main que par compensation fortuite : un dp_PT trop fort masquait un autre écart en aval (EP, ECS…, hors périmètre de cette issue) ;
• sur les 15 autres, 12 ont une sortie.deperdition_pont_thermique ADEME qui ne correspond pas à Σ l·k·pc des PT exportés (incohérence de l'export, ex. 2378E3808797H). Les 3 restants ont d'autres PT encore en écart, qui ne relèvent pas de cette règle.

Tous les scripts sont dans ~/work/i296 (scan.py, replay.mjs, an.py, ptbatch.mjs).

Closes #296