Corrige LE vrai bug : un nom de champ mot-réservé SQL (ex. "order") faisait disparaître l'objet entier

Reproduit à l'identique le cas signalé (objet "dialog" avec les champs
order/spiker/text/level_id/parcour_id) : le champ "order" est un mot
réservé SQL — "CREATE TABLE dialog (order INTEGER, ...)" plante avec
"OperationalError: near \"order\": syntax error". Comme ce crash survient
APRÈS l'INSERT de la ligne _definitions mais AVANT le commit(), rien
n'était jamais persisté : l'objet ENTIER disparaissait, malgré des champs
parfaitement remplis — d'où "j'ai tout rempli comme il faut et aucun objet
n'est créé". Mon précédent correctif (champ "Relation" sans cible) était
réel mais ne couvrait pas ce cas précis.

Cause de fond : chaque nom de colonne (dérivé du nom de champ tapé par
l'utilisateur, via slugify) était interpolé TEL QUEL dans du SQL brut
(CREATE TABLE, INSERT, UPDATE, ALTER TABLE ADD/DROP/RENAME COLUMN) sans
jamais être encadré de guillemets — n'importe quel nom de champ qui soit
aussi un mot réservé SQLite (order, group, index, select, where, table,
key, default, check, references, unique...) déclenchait exactement le
même crash-et-perte-de-transaction, dans n'importe laquelle de ces
opérations.

Correctif général (pas un simple contournement pour "order") :
db/quote_ident.py encadre tout identifiant de colonne de guillemets
doubles (forme standard SQL, supportée par SQLite) — appliqué partout où
un nom de colonne utilisateur est interpolé dans du SQL brut :
create_definition, add_field_to_definition, delete_field, update_field
(RENAME COLUMN), insert_row, update_row, update_row_field,
rows_referencing. Les noms de TABLE n'ont pas besoin de cette protection
(table_name_for.py les préfixe toujours "obj_", donc jamais un mot réservé
à eux seuls).

Trois nouveaux tests (tests/test_reserved_sql_keyword_field_names.py) :
création avec un champ "order" + insertion/lecture/mise à jour d'une
ligne, renommage d'un champ vers/depuis un mot réservé ("group"), ajout
d'un champ "select" à un objet existant — les trois confirmés en échec
sur l'ancien code (même erreur reproduite) puis au vert avec le
correctif. 136 tests au vert au total.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

db/definitions/create_definition.py

@@ -1,5 +1,6 @@
 from ..connection import connect
 from ..constants import FIELD_TYPES
+from ..quote_ident import quote_ident
 from ..slugify import slugify
 from ..table_name_for import table_name_for
 from .get_definition import get_definition
@@ -32,13 +33,13 @@ def create_definition(slug, name, fields):
             related = get_definition(slug, int(f["relation_definition_id"]))
             col = f"{fname}_id"
             columns_sql.append(
-                f"{col} INTEGER REFERENCES {related['table_name']}(id)"
+                f"{quote_ident(col)} INTEGER REFERENCES {related['table_name']}(id)"
             )
             relation_definition_id = related["id"]
         else:
             sql_type = FIELD_TYPES[ftype]["sql"]
             not_null = " NOT NULL" if required else ""
-            columns_sql.append(f"{fname} {sql_type}{not_null}")
+            columns_sql.append(f"{quote_ident(fname)} {sql_type}{not_null}")
 
         min_value = f.get("min_value") if ftype in ("nombre_entier", "nombre_decimal") else None
         max_value = f.get("max_value") if ftype in ("nombre_entier", "nombre_decimal") else None