fix(write-skill): la garde de chronologie ne vise que les factures ÉMISES

L'article 289 impose une numérotation chronologique et continue aux factures que
la société ÉMET. Il ne dit rien de la référence de classement que Dolibarr
attribue à celles qu'elle REÇOIT : le numéro qui fait foi pour ces dernières est
celui du fournisseur, porté par ref_supplier, et la séquence FAF suit l'ordre
d'ENREGISTREMENT — c'est sa construction normale, pas un défaut.

Appliquée aux deux registres, la garde produisait un faux positif systématique.
La production porte DÉJÀ cinq ruptures dans la séquence FAF — FAF2026003 daté du
4 janvier suit FAF2026002 daté du 9 — et ZÉRO dans la séquence FAC. Or adc-008
prescrit d'enregistrer une facture fournisseur à la date du document : le cas
ordinaire se heurtait donc au refus et exigeait ARCO_ALLOW_BACKDATE.

Une garde qu'on outrepasse par routine ne garde plus rien. Elle avait déjà été
outrepassée deux fois en une journée sur les factures Anthropic, et le même faux
positif avait été produit par le juge pré-gate sur le change-set d'indemnité —
signe que l'erreur était dans la règle, pas dans son application.

Vérifié sur les deux registres :
  facture FOURNISSEUR antidatée au 01/03  -> créée
  facture CLIENT      antidatée au 01/03  -> REFUSÉE (FAC008 au 23/07)

La garde protège désormais là où la loi s'applique, et cesse d'obstruer là où
elle ne s'applique pas.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

.claude/skills/dolibarr-sandbox-write/scripts/invoice-create.sh

@@ -194,6 +194,22 @@ fi
 # an earlier date, which is a numbering break. This bites whenever two documents
 # of the same cycle are issued on different days (a deferred part issued after
 # the next fixed part, for instance). Refuse rather than create the break.
+#
+# CUSTOMER INVOICES ONLY. L'article 289 impose une numérotation chronologique et
+# continue aux factures que la société ÉMET. Il ne dit rien de la référence de
+# classement que Dolibarr attribue aux factures qu'elle REÇOIT : le numéro qui
+# fait foi pour celles-là est celui du fournisseur, porté par ref_supplier, et la
+# séquence FAF suit l'ordre d'ENREGISTREMENT — c'est sa construction normale.
+#
+# Appliquer la garde aux deux registres produisait un faux positif systématique :
+# la production porte déjà cinq ruptures dans la séquence FAF (FAF2026003 daté du
+# 4 janvier suit FAF2026002 daté du 9), et zéro dans la séquence FAC. Toute
+# facture fournisseur enregistrée après coup — le cas ordinaire, cf. adc-008 qui
+# prescrit d'enregistrer à la date du document — se heurtait au refus et exigeait
+# ARCO_ALLOW_BACKDATE. Une garde qu'on outrepasse par routine ne garde plus rien.
+if [[ "${ENDPOINT}" != "/invoices" ]]; then
+  CHRONO_SKIP=1
+fi
 NEW_DATE="$(python3 -c "import json,sys; print(json.loads(sys.argv[1])['date'])" "${BODY}")"
 LAST="$("${W}" GET "${ENDPOINT}?sortfield=t.rowid&sortorder=DESC&limit=1" 2>/dev/null \
   | python3 -c "
@@ -204,7 +220,7 @@ try:
     else: print('0|-')
 except Exception: print('0|-')" 2>/dev/null || echo "0|-")"
 LAST_DATE="${LAST%%|*}"; LAST_REF="${LAST##*|}"
-if [[ "${LAST_DATE}" =~ ^[0-9]+$ ]] && (( LAST_DATE > 0 )) && (( NEW_DATE < LAST_DATE )); then
+if [[ -z "${CHRONO_SKIP:-}" ]] && [[ "${LAST_DATE}" =~ ^[0-9]+$ ]] && (( LAST_DATE > 0 )) && (( NEW_DATE < LAST_DATE )); then
   if [[ "${ARCO_ALLOW_BACKDATE:-}" != "I-UNDERSTAND-THIS-BREAKS-CHRONOLOGY" ]]; then
     printf 'invoice-create.sh: REFUSED — chronology break.\n' >&2
     printf '  new document dated %s, but %s is already issued at %s.\n' \