wallet: encrypt atomically under the SQLite backend

EncryptWallet() had only a Berkeley DB path: it rebuilt a wallet.dat temp
file and swapped it in. Under -walletbackend=sqlite that was wrong -- it
would leave the live wallet.sqlite unencrypted and write a divergent
wallet.dat instead. Add a SQLite persistence branch that rebuilds a fresh
wallet.sqlite in one transaction (public records copied from the live
store, encrypted key material serialized byte-for-byte the way the BDB
path writes it), checkpoints it, and swaps it in with a .before-encrypt
backup, mirroring the BDB rename dance. A fresh file rather than an
in-place rewrite keeps the change atomic and leaves no plaintext key in a
freed page.

CmdEncryptWallet skips PurgeDbEnvironmentLogs under SQLite (no Berkeley DB
environment behind the wallet) and reports the backend it used.

New wallet-sqlite-encrypt self-test drives the real command path in child
processes: export a wallet to SQLite, encrypt it through
-walletbackend=sqlite, and prove it comes out encrypted, unlockable with
the right passphrase, refusing the wrong one, with its recovery phrase
intact and the original wallet.dat left untouched.

1 files changed, 1 insertions, 0 deletions

diff --git a/src/makefile.mingw b/src/makefile.mingw
index 14e6b32..1cb47fb 100644
--- a/src/makefile.mingw
+++ b/src/makefile.mingw
@@ -112,6 +112,7 @@ tests: test_bip32.exe bitflash.exe
         ./bitflash.exe -selftest=wallet-sqlite-migration
         ./bitflash.exe -selftest=wallet-crypto
         ./bitflash.exe -selftest=wallet-encrypt
+        ./bitflash.exe -selftest=wallet-sqlite-encrypt
         ./bitflash.exe -selftest=net-message
         ./bitflash.exe -selftest=consensus-limits
         ./bitflash.exe -selftest=pool-stratum