gui: offer to convert a Berkeley DB wallet to SQLite on first run

A first-run dialog for an existing wallet.dat with no backend choice yet:
"Convert to SQLite" exports the wallet and records the sqlite marker so
the next start opens it; "Keep Berkeley DB" records that choice so the
offer does not return; "Decide later" leaves no marker and asks again.
wallet.dat is never touched, and the change takes effect on restart --
matching the restart-to-apply model.

The conversion itself is DoConvertWalletToSQLite(), a headless-testable
function the button calls: it reuses the export path (extracted as
ExportActiveWalletToSQLite, shared with -walletsqliteexport, which keeps
its own specific messages), refuses if already on SQLite or if a
wallet.sqlite exists, and writes the marker only after a verified export.

New wallet-convert self-test proves the action end to end: build a
Berkeley DB wallet, convert, and confirm wallet.sqlite + the marker are
written, wallet.dat is left untouched, a second convert refuses, and a
flagless restart opens the converted SQLite wallet with its phrase intact.
All wallet suites pass. The modal itself is thin UI over this tested
action.

1 files changed, 1 insertions, 0 deletions

diff --git a/src/makefile.mingw b/src/makefile.mingw
index 06c9211..55f186b 100644
--- a/src/makefile.mingw
+++ b/src/makefile.mingw
@@ -114,6 +114,7 @@ tests: test_bip32.exe bitflash.exe
         ./bitflash.exe -selftest=wallet-encrypt
         ./bitflash.exe -selftest=wallet-sqlite-encrypt
         ./bitflash.exe -selftest=wallet-backend-default
+        ./bitflash.exe -selftest=wallet-convert
         ./bitflash.exe -selftest=net-message
         ./bitflash.exe -selftest=consensus-limits
         ./bitflash.exe -selftest=pool-stratum