feat: ouvre la saisie des logements dans un tableau

La fiche compte une dizaine de champs pour une vingtaine de lots : un
formulaire par lot imposerait autant d'allers-retours. Le tableau garde
l'ergonomie du tableur d'où viennent ces données — une ligne par lot, les
colonnes dans le même ordre, chaque cellule enregistrée en la quittant.

Ce que le serveur calcule est affiché comme tel et non saisissable :
échéance du DPE (rouge si périmé, ambre à moins d'un an) et écart de
surface. Le type vu par le PDF reste visible à côté du type saisi quand les
deux se contredisent, plutôt que d'être remplacé sans le dire.

Tri et filtre vivent dans l'en-tête de chaque colonne, jamais au-dessus du
tableau : c'est là qu'on les cherche en lisant la colonne. Une liste de
choix peut proposer, dans un groupe à part, ce qui n'est pas une valeur de
la colonne — rattachement d'un lot aux comptes rendus, désaccord de type.
L'en-tête se fige au défilement, ce qui demande de borner la hauteur du
tableau : sans conteneur à hauteur limitée, `sticky` n'a rien à quoi se
tenir.

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

frontend/src/style.css

@@ -112,6 +112,15 @@
     @apply cursor-pointer;
   }
 
+  /* Champ de saisie dans une cellule de tableau. Bordure invisible au repos :
+     une grille de 14 colonnes encadrees serait illisible, alors qu'un tableau
+     de saisie doit d'abord se lire. */
+  .input-cell {
+    @apply bg-transparent border border-transparent rounded px-2 py-1 text-sm text-white
+           placeholder-gray-600 hover:border-gray-700 focus:outline-none focus:border-blue-500
+           focus:bg-gray-950 transition-colors [color-scheme:dark];
+  }
+
   .form-hint {
     @apply text-xs text-gray-500 mt-1;
   }