fix(notebook-tools): rename_notebooks.py laisse un 404 silencieux quand un lien relatif change de repertoire #19154

Ce qui se passe

scripts/notebook_tools/rename_notebooks.py réécrit le basename d'un lien relatif mais jamais
son préfixe de répertoire. Quand la cible change de dossier, le lien produit pointe un chemin qui
n'existe pas — un 404 silencieux : l'organe écrit le fichier, et seuls les gardes CI le
découvrent après coup.

Mesure (PR #19151, mouvement 09d → Discrepancy/)

Table de mapping :

Résultat : MyIA.AI.Notebooks/SymbolicAI/Lean/Lean-08-Agentic-Proving-Python.ipynb a reçu

[Search-09d](../../Search/Part1-Foundations/Discrepancy-02-Komlos-Lean.ipynb)

— le nom a suivi, le dossier non (Part1-Foundations/ au lieu de Discrepancy/).

Le git mv a de plus cassé, dans le notebook déplacé lui-même, ses liens vers Search-09c (son
voisin de dossier avant le mouvement). La CI n'en a signalé qu'un des six ; les trois du notebook
déplacé lui sont structurellement invisibles, puisque le fichier est déplacé et que le garde ne
recompare pas ses liens internes à sa nouvelle base.

Mécanisme

build_patterns() (l.444-476) construit quatre formes par renommage — full, filename, stem,
urlencoded — triées par longueur décroissante. Sur un lien relatif, seule la forme filename
matche : le préfixe ../../Search/Part1-Foundations/ survit intact.

Le commentaire l.469-472 dit qu'« un référent embarqué dans un chemin relatif est un référent comme
un autre ». C'est vrai du nom, faux du chemin : le préfixe est justement ce qu'il faut
recalculer, et rien dans l'outil ne le fait.

Comportement attendu

Deux options, la seconde étant la plus petite :

1. Recalculer le préfixe relatif — résoudre le lien depuis le fichier porteur, appliquer le
   déplacement, réécrire le chemin relatif complet. C'est le geste juste, mais il demande de
   distinguer un lien d'une mention en prose.
2. Refuser en fail-closed un fichier qui contient un lien relatif dont la cible change de
   dossier — c'est exactement la doctrine que l'outil applique déjà aux cellules de code (I2) et aux
   sorties committées (I3). Un refus se voit dans le plan ; un 404 silencieux, non.

L'organe check_notebook_navlinks.py figure bien dans organ_argv() (l.724), mais il tourne
après l'écriture : il signale au lieu d'empêcher. La garde fail-closed de rewrite_file
(l.685-707) ne couvre que les surfaces ipynb, pas la validité des liens.

Point connexe, à trancher plutôt qu'à corriger ici

Lean-07b-Examples-Python.ipynb a été refusé en bloc parce qu'une cellule de code (cellule
30) cite l'ancien nom — alors que son lien markdown (cellule 28) était réparable et l'a été
manuellement dans #19151. Le refus en bloc est défendable (il évite un état mixte), mais il laisse un
404 que l'outil aurait pu nommer comme résidu dans son plan. Une sortie « surfaces refusées +
occurrences restantes par surface » rendrait le résidu directement actionnable.

Références

• PR refactor(search,#17802): descente de 09d dans Discrepancy/ -- Discrepancy-02-Komlos-Lean #19151 — mouvement et réparation (tête 2d0ec03d), commentaire c.5984464731
• Chantier Search(#5081): lecture de gradation de la serie — escalier, lettres greffees ICT, dette zero-pad et sous-series candidates #17802 — gradation Search