refactor(db): drop cleartext template refs, fix ghost columns + fresh-DB schema

Migration verified (0 unmigrated cleartext templates across both accounts)
before contracting:
- GET/POST/PUT/bulk no longer read or write the cleartext template column
  (only template_enc/iv); the PUT partial-update gate stays keyed on the
  'template' JSON key presence.
- Removed AddColumnIfMissing for template AND tags/title — those two had
  silently re-added the dropped columns as empty ghosts at every start.
- CREATE TABLE: removed site/username NOT NULL cleartext columns — a FRESH
  database rejected the very first INSERT (which no longer ships them).

User can now DROP COLUMN template (and re-drop the ghost tags/title).

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

CODE_AUDIT.md

@@ -105,9 +105,11 @@ recherche/favicons OK. La migration est **par utilisateur** (tourne au unlock
 sur les entries du compte connecté) — un compte non connecté garde son clair
 jusqu'à sa prochaine connexion (comportement normal, pas une régression).
 **`template` chiffré au repos (✅ 2026-07-11)** : même pattern
-(`template_enc`/`template_iv`, ajouté à `ENCRYPTED_META_FIELDS`). Colonne clair
-`template` gardée comme fallback de migration (`decryptEntryMeta` préfère `_enc`,
-retombe sur le clair). Guard dans `withEncryptedMeta` : les re-ships partiels
+(`template_enc`/`template_iv`, ajouté à `ENCRYPTED_META_FIELDS`). Migration
+vérifiée (0 clair restant, 2 comptes) → refs colonne clair retirées du code +
+`AddColumnIfMissing` supprimés (template, et tags/title qui étaient revenus en
+fantômes après le drop) + CREATE TABLE corrigé (site/username NOT NULL cassait
+une DB neuve). Guard dans `withEncryptedMeta` : les re-ships partiels
 (add-tag, move-to-folder) omettent `template` → le serveur le préserve via
 `LHasTemplate` (clé absente), pas de wipe. 3 tests unitaires.
 **Pièces jointes : le contenu est déjà chiffré** (AES-GCM, `encryptBlobBytes`) ;