wallet: clearer refusal for an empty or misnamed SQLite backend

Review follow-up on the SQLite activation. Two guards, both fail-closed;
neither is a correctness fix -- FinishLoadedWallet already refuses a
missing default key -- but they make the refusal say what happened:

- an empty or non-wallet wallet.sqlite is refused with "no default key
  record; it may be empty or not a wallet export", instead of the generic
  "no usable default public key" that reads as corruption;
- a misspelled -walletbackend value (e.g. sqlit) is refused instead of
  silently falling through to Berkeley DB; -walletbackend=bdb is accepted
  as the explicit default.

1 files changed, 16 insertions, 0 deletions

diff --git a/src/db.cpp b/src/db.cpp
index c4ea81e..771a4ba 100644
--- a/src/db.cpp
+++ b/src/db.cpp
@@ -1496,6 +1496,22 @@ bool LoadWalletFromSQLiteRuntime(const string& strPath)
         return false;
     }
 
+    // Refuse an empty or non-wallet SQLite file up front, with a message that
+    // names the likely cause. FinishLoadedWallet below already rejects a
+    // missing default key (it is the fMayCreateDefaultKey=false path), but its
+    // wording -- "no usable default public key" -- reads as corruption when the
+    // real story is usually "this file was never an exported wallet". A blank
+    // wallet.sqlite left by a typo or a half-run export should say so.
+    if (visitor.vchDefaultKey.empty())
+    {
+        WalletSQLiteRuntimeClose();
+        strWalletLoadError =
+            "SQLite wallet has no default key record; it may be empty or not a "
+            "wallet export. Create it with -walletsqliteexport.";
+        printf("LoadWallet: %s\n", strWalletLoadError.c_str());
+        return false;
+    }
+
     if (!ReconcileLoadedWalletMetadata(visitor.fHaveStoredMineMode,
                                        visitor.fHaveStoredHDCoinType))
     {