docs(lite): clarify SDXL viewing-key HRP differs from the full node

Audit of the lite import path found no false-rejection defect (no client-side
gate; the two-command fallback in importKey makes the U/5/K/L prefix guess
non-binding; lite send reuses the now-P2SH-fixed send_tab helpers). But the
"zxview" viewing-key comment — which was WRONG in the full node (fixed earlier)
— is genuinely CORRECT here: SDXL's import takes an extended full viewing key
(zxviews…, hrp_sapling_viewing_key), whereas the full node's z_importviewingkey
takes an incoming viewing key (zivks…). The two are not interchangeable.

Add a note so nobody "harmonizes" the two gates and reintroduces the full-node
bug. Comment-only; no behavior change.

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

src/wallet/lite_wallet_controller.cpp

@@ -887,6 +887,11 @@ LiteImportResult LiteWalletController::importKey(std::string spendingOrViewingKe
     }
     // Transparent WIFs begin with U/5/K/L (TImportCommand); shielded keys begin with
     // "secret-..." / viewing keys "zxview...", so this prefix check usually won't collide.
+    // NB: the lite/SDXL backend's viewing key is an *extended full* viewing key ("zxviews…",
+    // hrp_sapling_viewing_key), which is genuinely correct here — do NOT "harmonize" this with the
+    // full node, whose z_importviewingkey takes an *incoming* viewing key ("zivks…") instead. The
+    // two variants accept different viewing-key forms; a VK is not portable between them. Regardless,
+    // the two-command fallback below means a mis-guessed prefix never rejects an otherwise-valid key.
     const char first = spendingOrViewingKey[0];
     const bool transparentFirst = (first == 'U' || first == '5' || first == 'K' || first == 'L');