fix(build): lier SQLite dans l'exe, qui chargeait sqlite3.dll du PATH

Sans FireDAC.Phys.SQLiteWrapper.Stat, FireDAC charge sqlite3.dll au
demarrage. Sur ce poste ca marchait quand meme : le dossier bin
d'Embarcadero, qui en contient un, est dans le PATH. Sur une machine
sans Delphi, l'exe refusait de demarrer.

C'est le Win64 qui l'a revele — la DLL du PATH est 32 bits — mais le
Win32 livre etait casse de la meme facon chez quiconque n'a pas Delphi,
paquet prepare pour un tiers compris.

Prouve avec un PATH reduit a Windows : avec l'unite SQLite s'ouvre
(3.42.0), sans elle l'erreur exacte. Lire la table d'import ne
suffisait pas, le chargement est dynamique.

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

CLAUDE.md

@@ -1435,6 +1435,20 @@ le vide ET vide `FPendingURL` → écran noir permanent sur cold-start lent.
   sources TMS. L'exe de `E:\password manager\` cree **son propre `vault.db`** a
   cote de lui, sans `config.txt` : ni le coffre de `delphi-backend\`, ni celui
   de `E:\a pmanager\`.
+- **SQLite doit etre LIE dans l'exe : `FireDAC.Phys.SQLiteWrapper.Stat` dans
+  `PM.Database`.** Sans cette unite, FireDAC **charge `sqlite3.dll`** au
+  demarrage. Le piege : **sur un poste de developpement ca marche quand meme**,
+  parce que `…\Embarcadero\Studio\23.0\bin\sqlite3.dll` est dans le PATH. On
+  croit donc livrer un exe autonome ; sur une machine sans Delphi il refuse de
+  demarrer (`[FireDAC][Phys][SQLite]-314 Cannot load vendor library`). C'est
+  le Win64 qui l'a revele — la DLL du PATH est 32 bits, donc introuvable pour
+  lui — mais le **Win32 livre jusqu'au 2026-09-16 etait casse de la meme facon**
+  chez quiconque n'a pas Delphi, y compris le paquet prepare pour un tiers.
+  Prouve avec un PATH reduit a `C:\Windows\System32;C:\Windows` : avec l'unite
+  « SQLite OUVERT 3.42.0 », sans elle l'erreur exacte. `Stat` et non `FDEStat` :
+  le coffre est un SQLite ordinaire, le chiffrement se fait cote JavaScript.
+  **Pour verifier qu'un exe est vraiment autonome, retirer Delphi du PATH** —
+  lire la table d'import ne suffit pas, le chargement est dynamique.
 - **Win64 (active le 2026-09-16).** Le groupe `Base_Win64` du `.dproj` etait
   quasi vide : **ni prefixes d'unites** (`Winapi;System.Win;…`), d'ou
   `F2613 Unite 'Windows' non trouvee` en recompilant TMS, **ni `Cfg_1_Win64`**