fix(chat): tear down the chat session immediately on lite wallet lock

Security-review finding (low): on the lite variant, "Lock now" ran the backend
`lock` but never updated state_.locked — that only refreshes on the next ~2s
poll. Since chat teardown is driven by state_.isLocked() in maybeProvision
ChatIdentity, the decrypted in-memory store, the chat identity secret key, and
the seed-derived AEAD DB key all lingered in RAM for up to ~2s past an explicit
lock (the full-node path closes this immediately, since App::lockWallet sets
state_.locked synchronously).

New App::lockLiteWallet() mirrors the full-node behavior: on a successful lite
lock it sets state_.locked and tears down the chat session now (clearIdentity +
store().clear() + chat_db_.lock() + re-arm). The lite "Lock now" button routes
through it. (Note: the lite variant has no auto-lock at all — checkAutoLock ->
App::lockWallet early-returns for lite — which is a separate, general lite gap.)

Completes the end-to-end feature security review (1 confirmed finding of 3 raw,
now fixed). Verified: Linux + Windows build with chat ON, ctest 100%, hygiene clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

src/app.h

@@ -182,6 +182,9 @@ public:
     const std::string& liteOpenError() const { return lite_open_error_; }
     // Show the lite send-time unlock modal (called when a spend is attempted on a locked wallet).
     void requestLiteUnlock() { lite_unlock_prompt_ = true; }
+    // Lock the lite wallet AND immediately tear down the chat session (the lite backend `lock`
+    // doesn't update state_.locked until the next poll, so chat secrets would otherwise linger).
+    bool lockLiteWallet();
     // (Re)build the lite controller from current settings so a changed lite-server selection
     // takes effect. No-op on non-lite/unlinked builds; preserves a live wallet (see app.cpp).
     void rebuildLiteWallet(bool force = false);