fix(ci+storage): unblock Python 3.12 shutdown hang on ubuntu

Symptôme CI Python 3.12 ubuntu :
pytest finit en 3:21 (5013 passed)
interpréteur reste 12 min en hang
runner GitHub timeout 15 min → "action timed out"

Cause racine
============

picarones/adapters/storage/job_store.py utilisait le pattern :

with self._connect() as conn:
conn.execute(...)

Or le __exit__ de sqlite3.Connection ne fait QU'UN COMMIT,
**pas un close()**. Chaque appel à une méthode du JobStore créait
une nouvelle connexion qui n'était jamais fermée explicitement.

Sur Python 3.12+ le GC de fin d'interpréteur tente de fermer les
milliers de connexions accumulées (5013 tests × N opérations),
ce qui peut bloquer plusieurs minutes — observable d'autant plus
clairement que 3.12 a renforcé le warning ResourceWarning sur les
ressources non fermées (compte de warnings : 51 sur 3.11 → 85 sur
3.12 → 341 sur 3.13).

Sur 3.11 le shutdown finissait dans la fenêtre du timeout-minutes
de 15 ; sur 3.12 ubuntu il dépassait.

Fix
===

1. JobStore._connect est un @contextlib.contextmanager qui
yield la connexion puis conn.close() en finally. Plus
de fuite, plus de hang au shutdown.

2. CI durci avec garde-fous anti-hang :

- timeout-minutes: 12 au step Run tests (était 15).
- timeout GNU autour de pytest : SIGTERM à 9 min,
SIGKILL 30s après si Python n'obéit pas. Le shutdown
ne peut plus monopoliser le job.
- python -X faulthandler + PYTHONFAULTHANDLER=1 :
dump des stack traces de tous les threads avant SIGKILL —
diagnostic immédiat si un nouveau hang apparaît.
- Détection timeout (Linux GNU) / gtimeout (macOS
Homebrew) / fallback Python direct (Windows).

3. tests/conftest.py : pytest_sessionfinish enumère les
threads vivants en fin de session et programme un
faulthandler.dump_traceback_later(60) qui dumpera les
stack traces si l'interpréteur ne sort pas dans la minute.

Vérification locale
===================

Tests : 5016 passed, 12 skipped, 8 deselected, 0 failed.
Lint : ruff check picarones/ tests/ clean.
La fuite n'apparaissait pas en pytest local sur 3.11 mais le fix
est sain sur toutes les versions Python.

.github/workflows/ci.yml

@@ -92,22 +92,55 @@ jobs:
       # ── Tests ───────────────────────────────────────────────────
       # Sprint A1 : --cov-fail-under=85 (baseline mesuré 87 %, marge 2 pts).
       # pytest-timeout est configuré dans pyproject.toml [tool.pytest.ini_options].
-      # ``timeout-minutes`` au niveau step : le job ne hang JAMAIS plus de
-      # 15 min sur les tests, même si pytest-timeout (par-test) échoue à
-      # cleanup un thread daemon.
+      #
+      # Garde-fous anti-hang :
+      #
+      # 1. ``timeout-minutes: 12`` au niveau step : cap dur GitHub si
+      #    tout le reste échoue.
+      # 2. ``timeout`` GNU autour de pytest : SIGTERM à 9 minutes,
+      #    SIGKILL 30s après si Python n'a pas obéi.  Couvre
+      #    spécifiquement le cas d'un hang de SHUTDOWN de
+      #    l'interpréteur Python 3.12+ (threads non-daemon, connexions
+      #    sqlite non fermées, ResourceWarnings — observé sur ubuntu
+      #    3.12 où pytest finit en 3:21 et l'interpréteur reste 12 min
+      #    avant de rendre la main).
+      # 3. ``-X faulthandler`` : si le hang revient, on aura les stack
+      #    traces de tous les threads dans le log avant le SIGKILL.
+      # 4. ``PYTHONFAULTHANDLER=1`` redondance ceinture-bretelles.
+      #
+      # Le code de retour 124 (SIGTERM par GNU timeout) ou 137 (SIGKILL)
+      # est traité comme un échec normal — on perd l'info pytest mais
+      # on préserve la latence de la CI.
       - name: Run tests
         # Sur Python 3.13, on continue malgré une erreur pour ne pas bloquer
         # le merge pendant la fenêtre informationnelle de 6 mois (m-8).
         continue-on-error: ${{ matrix.python-version == '3.13' }}
-        timeout-minutes: 15
+        timeout-minutes: 12
         shell: bash
         run: |
-          pytest tests/ -q --tb=short --no-header \
-            --cov=picarones --cov-report=xml --cov-report=term-missing \
-            --cov-fail-under=85
+          # ``timeout`` n'est pas standard sur macOS (BSD vs GNU) — on
+          # détecte et on adapte.  Sur Windows, le shell bash de
+          # Git-Bash n'a pas timeout : on retombe sur python direct.
+          if command -v timeout >/dev/null 2>&1; then
+            timeout --signal=SIGTERM --kill-after=30 540 \
+              python -X faulthandler -m pytest tests/ -q --tb=short --no-header \
+                --cov=picarones --cov-report=xml --cov-report=term-missing \
+                --cov-fail-under=85
+          elif command -v gtimeout >/dev/null 2>&1; then
+            # macOS Homebrew coreutils.
+            gtimeout --signal=SIGTERM --kill-after=30 540 \
+              python -X faulthandler -m pytest tests/ -q --tb=short --no-header \
+                --cov=picarones --cov-report=xml --cov-report=term-missing \
+                --cov-fail-under=85
+          else
+            python -X faulthandler -m pytest tests/ -q --tb=short --no-header \
+              --cov=picarones --cov-report=xml --cov-report=term-missing \
+              --cov-fail-under=85
+          fi
         env:
           PYTHONIOENCODING: utf-8
           PYTHONUTF8: "1"
+          PYTHONFAULTHANDLER: "1"
 
       # ── Couverture ──────────────────────────────────────────────
       # Conditions :

picarones/adapters/storage/job_store.py

@@ -59,6 +59,7 @@ from __future__ import annotations
 
 import json
 import logging
+import contextlib
 import sqlite3
 import time
 from collections.abc import Callable
@@ -248,23 +249,37 @@ class JobStore:
     def db_path(self) -> Path:
         return self._path
 
-    def _connect(self) -> sqlite3.Connection:
-        """Ouvre une nouvelle connexion.
+    @contextlib.contextmanager
+    def _connect(self):
+        """Ouvre puis ferme une connexion SQLite.
 
         ``timeout=30s`` côté driver Python + ``PRAGMA busy_timeout``
         côté SQLite absorbent les contentions courtes.  Le mode
         autocommit combiné au journal WAL garantit que les lectures
         n'attendent pas les écritures (cf. https://sqlite.org/wal.html).
+
+        Pourquoi un contextmanager dédié plutôt que ``with
+        sqlite3.connect(...)`` directement : le ``__exit__`` de
+        ``sqlite3.Connection`` fait UN COMMIT, pas un ``close()``.
+        Sur Python 3.12+, les connexions non fermées s'accumulent et
+        leur libération via GC au shutdown de l'interpréteur peut
+        bloquer le process plusieurs minutes (observé sur ubuntu
+        3.12 — pytest finit en 3:21, l'interpréteur reste 12 min en
+        hang avant SIGKILL du runner CI).  ``yield + close()`` dans
+        ``finally`` garantit la libération immédiate.
         """
         conn = sqlite3.connect(
             str(self._path),
             isolation_level=None,  # autocommit pour simplicité
             timeout=30.0,
         )
-        # busy_timeout (ms) — backup au timeout Python.
-        conn.execute("PRAGMA busy_timeout = 30000;")
-        conn.row_factory = sqlite3.Row
-        return conn
+        try:
+            # busy_timeout (ms) — backup au timeout Python.
+            conn.execute("PRAGMA busy_timeout = 30000;")
+            conn.row_factory = sqlite3.Row
+            yield conn
+        finally:
+            conn.close()
 
     # ──────────────────────────────────────────────────────────────
     # Création / lecture

tests/conftest.py

@@ -47,3 +47,51 @@ os.environ.pop("PICARONES_PUBLIC_MODE", None)
 
 # Rate limit désactivé en dev (déjà le défaut, explicité ici).
 os.environ.setdefault("PICARONES_RATE_LIMIT_PER_HOUR", "0")
+
+
+def pytest_sessionfinish(session, exitstatus) -> None:  # noqa: ARG001
+    """Diagnostic du shutdown de l'interpréteur.
+
+    Sur Python 3.12 ubuntu-latest, l'interpréteur restait jusqu'à 12
+    minutes en hang après ``=== passed ===`` à cause de threads
+    non-daemon ou de connexions sqlite non fermées que les tests
+    avaient laissés.
+
+    Ce hook :
+
+    1. Liste les threads vivants à la fin de la session — si la
+       liste contient autre chose que ``MainThread``, le développeur
+       voit immédiatement quelle ressource fuit.
+    2. Force le flush stdout/stderr pour que le diagnostic apparaisse
+       même si l'interpréteur hang ensuite.
+    3. Programme un ``faulthandler.dump_traceback_later(60)`` qui
+       dumpera les stack traces de TOUS les threads après 60s
+       d'inactivité — ce qu'on a besoin pour identifier la fuite si
+       le hang persiste.
+    """
+    import faulthandler
+    import sys
+    import threading
+
+    alive = [
+        t for t in threading.enumerate()
+        if t is not threading.main_thread() and t.is_alive()
+    ]
+    if alive:
+        sys.stderr.write(
+            "\n[conftest] threads encore vivants au sessionfinish "
+            f"({len(alive)}) :\n",
+        )
+        for t in alive:
+            sys.stderr.write(
+                f"  - name={t.name!r} daemon={t.daemon} "
+                f"alive={t.is_alive()}\n",
+            )
+        sys.stderr.flush()
+
+    # Si le shutdown hang plus de 60s, on aura les stack traces.
+    faulthandler.dump_traceback_later(
+        timeout=60,
+        repeat=False,
+        file=sys.stderr,
+    )