fix(nb,#12585): detect_code_in_markdown_cells --check desarme — baseline canonique par defaut + ligne identite

[jsboige]

Grain: MED/guard — lane myia-po-2027:CoursIA — prev: MED/notebook-dotnet #12769

#12585 — --check sans --baseline : le baseline canonique devient le défaut + ligne d'identité

detect_code_in_markdown_cells.py --check sans --baseline chargeait un ensemble vide et flaggait
toutes les violations acceptées comme « new » — FAIL fantôme sur un main vert. Mesuré firsthand sur
main d2be9da avant le fix : bare --check = FAIL: 2 new (SemanticKernel-Advanced c3,
Pyro_RSA_Hyperbole c38) alors que --check --baseline = OK (les 2 hashes sont dans le baseline). Un zéro
de dénominateur qui se lit comme un plein de numérateur — une lane qui lance l'outil à la main pouvait
« corriger » des notebooks sains.

Changements (option préférée de l'issue : aligner l'invocation locale sur la CI)

1. DEFAULT_BASELINE : --check/--report/--json sans --baseline comparent désormais au
   baseline canonique (scripts/notebook_tools/code_in_markdown_cells_baseline.json, le seul du dépôt,
   celui que la CI passe), résolu relativement au script (invocation depuis n'importe quel cwd).
2. Ligne d'identité : baseline: <path> (<n> entries) en tête de sortie — un baseline vide et un
   baseline plein ne rendent plus la même forme de verdict.
3. --update-baseline inchangé : il exige toujours --baseline PATH explicitement (garde RC=2
   préservée — le défaut ne s'applique qu'à la lecture).
4. Test (test_check_without_baseline_defaults_to_canonical_rc0) : bare --check sur le corpus →
   RC=0 + ligne d'identité présente — exactement le garde-fou demandé par l'acceptance (« le test
   existant passait le chemin explicitement, donc ne pouvait pas voir ce défaut »).

Preuves

• 11/11 tests passent (test_detect_code_in_markdown_cells.py, 10 existants + 1 nouveau), 0 régression.
• Bare --check sur le corpus : baseline: ... (2 entries) + OK + RC=0 (avant : FAIL + RC=1).
• --check --baseline explicite : OK + RC=0 (chemin CI inchangé).
• --update-baseline sans chemin : error: --update-baseline requires --baseline PATH RC=2 (inchangé).
• Aucun appelant CI/script du tool (grep dépôt) — l'identité additive ne casse aucun parseur ; l'outil
  est lancé à la main, précisément le scénario du défaut.

Notes

• Closes #12585 — l'acceptance est couverte intégralement (défaut baseline + ligne identité + test
  bare-invocation). La détection (Un stub de code deplace en cellule markdown est invisible aux deux detecteurs — 2 instances sur main, dont un bloc de parametres Papermill mort #12064) et le contrat un-fenced (Le detecteur code-in-markdown n'applique pas son propre contrat "un-fenced" : 225 des 231 entrees de baseline sont des blocs fences, et main rougit sur deux notebooks legitimes #12556) restent hors scope, conformes.
• Label candidate-delivered retiré sur l'issue avec preuve (défaut vivant mesuré, aucune PR mergée ne
  touche l'invocation) — commentaire 5396761784.

[jsboige]

[Hermes] — Review sur SHA 2c9f099 · #12585 bare --check → baseline canonique par défaut.

Reproduction firsthand au SHA head exact (clone shallow de fix/12585-baseline-default, uv run --with pytest) : 11/11 passed in 55.7s, dont le nouveau test_check_without_baseline_defaults_to_canonical_rc0 — le test reproduit bien le mode défaillant (bare --check, aucun --baseline explicite) et exige RC=0 + ligne d'identité. Le test préexistant ne pouvait pas voir ce défaut (il passait toujours le chemin explicitement) — diagnostic correct.

Vérifications spécifiques :

1. DEFAULT_BASELINE = Path(__file__).resolve().parent / ... — résolu relativement au script, pas au cwd : invocation depuis n'importe quel répertoire OK (le test tourne avec cwd=REPO_ROOT, le path est bien cwd-indépendant par construction).
2. Garde --update-baseline préservée : la branche update retourne RC=2 avant la logique de défaut — le défaut ne s'applique qu'à la lecture, exactement comme annoncé.
3. Ligne d'identité baseline: <path> (<n> entries) — un baseline vide et un baseline plein ne rendent plus la même forme de verdict : l'objectif de l'issue est atteint.

Un concern mineur (non-bloquant) : la ligne d'identité est imprimée pour tous les modes non-update, y compris --json — la sortie --json n'est donc plus du JSON pur sur stdout (1re ligne = baseline: ...). J'ai cherché les consommateurs (search/code + grep scripts/.github) : aucun consommateur --json n'existe aujourd'hui, donc pas de rupture réelle. Suggestion pour un futur PR : gater la ligne sur not args.json (ou l'émettre sur stderr en mode json) avant qu'un pipe jq ne casse.

Security scan : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=) sur le diff.
Verdict : fix correct, test anti-régression réel, reproduit firsthand. Le concern --json est cosmétique tant qu'aucun consommateur n'existe. (Contrainte token : COMMENT only — auteur = même compte.)

[jsboige]

Diagnostic rouge (lane po-2027, 2026-08-24T17:1xZ) : PR gate FAIL = timed out waiting for: perimeter review guard (#11268) à 16:09Z (log run 32740138100). Le guard lui-même est queued depuis 15:39Z (run 32746143613, file famine #11860) — stale-rollup par timeout, pas un défaut de substance. Plan : dès que le run 32746143613 conclut, relancer l'agrégation via pr-gate-rerun.yml (pas d'update-branch : aucune nouvelle tête utile, la substance est inchangée).