PT-02 : arbitrer l'épinglage éventuel d'un train_runtime mesuré fraîchement (suivi CAUSE_DOCUMENTED_ONLY de #15310) #15409

Contexte

Issue de suivi issue de la réparation de PR #15310 (voir ## Diagnostic dérive dans son body, cycle c.357). Verdict du diagnostic : CAUSE_DOCUMENTED_ONLY — la ligne Trace réelle mesurée du PT_02_sft_baseline.ipynb portait un train_runtime 66,44 s + RTX 3070 8 Go épinglés sans exécution fraîche attestable à ce head (cause (b) : claim antérieure fabriquée, non un défaut de code).

La réparation #15310 retire la valeur de la prose (forme §C.5 de la base restaurée). §C.5 du harnais de conformité tranche déjà : un temps absolu machine-dépendant se retire quand le notebook est ré-exécutable ailleurs.

Question tranchée par cette issue

Faut-il, malgré §C.5, épingler un train_runtime mesuré fraîchement dans la prose du PT-02 ?

• Option A (statu quo réparé) : non — la valeur reste retirée ; cette issue se ferme comme documentée.
• Option B : oui — alors une re-exécution fraîche sur GPU ≥ 8 Go est requise (ai-01 : 3× RTX 4090 24 Go mesurés), la trace ré-épinglée doit porter la nouvelle mesure + le matériel effectif, et la cellule concernée doit être re-exécutée (C.2), pas seulement la prose.

Critères d'acceptation

• Option arbitrée (A ou B) avec justification écrite
• Si B : PR avec exécution réelle (execution_count + outputs cohérents) et valeurs mesurées au head courant
• Le body de fix(genai): PT-02 prose realignee sur les sorties post-#12716 (runtime 66,44 s + collapse reinterpreté) #15310 référence cette issue (corrigé au moment de l'ouverture)

Refs : #15310 (réparation c.357/c.358), #15265 (issue d'origine).