output-failure ratchet: faux positif sur cellule byte-identique a la base (condition #19038 ne verifie pas que la sortie a change) #19877

Sans parent : organe autonome (gate Output-failure ratchet), fondé par #11685 et durci par #19038 (issue #18916) -- tous deux clos. Voisin de #19870 : même famille, une exemption de gate qui ne vérifie pas la condition qu'elle est censée détecter.

Le défaut

scripts/notebook_tools/check_output_failure_text.py, fonction _declared_fallback (condition de base introduite par #19038) :

base_cell = _base_cell_for(base_nb, cell)
if base_cell is not None and _substantial_output(base_cell):
    return False   # -> reste TOOL_FAILURE

L'intention documentée : « la bannière a REMPLACÉ un rendu, c'est une perte de capacité ». Mais la condition ne vérifie jamais que la sortie de la cellule a changé entre base et head. Elle nie l'exemption dès que la cellule de base portait une sortie substantielle -- y compris quand la cellule de head est byte-identique (id, source ET sorties) à la base. Or une cellule identique n'a rien remplacé : la bannière était déjà là, committée sur main.

L'asymétrie vient de compare() : la base est scannée sans base_nb (choix documenté, sain par ailleurs), donc sa bannière déclarée y est comptée DECLARED_FALLBACK ; le head est scanné avec la base, où la même bannière devient TOOL_FAILURE. Delta 0 -> 1 sur une cellule que la branche n'a pas touchée.

Mesure (PR #19831, RL/RL-06d-SAC-Depuis-Zero-Python.ipynb)

La branche modifie une ligne du carnet (un titre markdown de section). La cellule 39 (id=2614768a, exercice 3 : adapter SAC) :

Scan reproduit en local :

BASE TOOL_FAILURE: []
BASE DECLARED    : [(39, 'non disponible')]
HEAD TOOL_FAILURE: [(39, 'non disponible')]
HEAD DECLARED    : []

check_output_failure_text.py origin/main -> FAIL ... TOOL_FAILURE: 0 -> 1 (+1), exit 1 -- alors que le diff du carnet est 1 file changed, 1 insertion(+), 1 deletion(-) (un titre markdown).

La bannière est imprimée par la source de la cellule elle-même (try/except de l'exercice, littéral dans la source) : c'est le repli pédagogique conçu, présent sur main, inchangé par la PR.

Pourquoi aucune action de lane ne verdit ce rouge

• Ré-exécuter la cellule sans box2d redonne la même bannière -> delta inchangé, rouge persiste.
• Installer box2d puis ré-exécuter changerait le contenu pédagogique du carnet (l'exercice 3 passe de son repli Pendulum à LunarLander) et les sorties de tout le carnet -- un scope explosion pour une PR d'une ligne markdown.
• Corriger l'organe dans la PR qu'il bloque est hors périmètre (même règle que md-content-loss: faux positifs quand une PR substitue une cellule markdown (ensembles d'ids inegaux -> appariement par index) #19870).

Correctif proposé (non appliqué ici)

Nier l'exemption seulement quand la bannière a réellement remplacé quelque chose :

if (base_cell is not None and _substantial_output(base_cell)
        and _cell_output_text(cell) != _cell_output_text(base_cell)):
    return False

• Cas fondateur fix(guard,#18916): ratchet output-failure distingue le fallback DÉCLARÉ du mode démo (Lean-10) #19038 (bannière remplace un rendu) : les sorties diffèrent -> toujours nié -> toujours TOOL_FAILURE. Le replay du self-test est préservé.
• Nouveau contrôle négatif : cellule byte-identique avec sortie substantielle -> DECLARED_FALLBACK, delta 0.
• Contrôle complémentaire : base substantielle + bannière, head réduit à la seule bannière (quelque chose a été perdu) -> toujours nié.

Attendu : fixture de regression dans --self-test construite sur ce cas, et rejeu local sur le couple base/head de RL-06d qui passe de FAIL (1 regressed) à 0 regressed.

Contexte de la mesure : PR #19831 (gate rouge à la tête 85f299bde8a).