fix: explain a stored non-master xprv wallet instead of throwing at signing time (closes #234)

An xprv wallet imported before non-master keys were refused holds a key
whose depth is greater than zero. Its addresses were derived by applying
the Ethereum path beneath that key, so they are not the addresses the key
produces under the standard path, and signing for them now throws — on the
send screen, with no explanation.

Detect it at wallet-list render time instead. An xprv wallet stores the
neutered node four levels below the imported key, so a master import stores
a depth-4 xpub and a depth-d import stores depth d + 4; the stored xpub is
therefore an exact read on the imported key's depth and needs no password.

The wallet list renders a named explanation under the wallet's name, the
"+" button is withheld, and send, dapp transaction approval, dapp message
signing and private-key export all refuse before asking for a password.
getSignerForAddress remains the backstop and now says why in a sentence.

The copy states what is true and nothing more: the addresses do descend
from the key that was imported, so it neither promises the funds are safe
nor implies anything was lost. The wallet is not deleted or rewritten.

TODO.md

@@ -44,6 +44,11 @@ undefined identifiers, which is how
 
 # Completed Steps
 
+- 2026-08-12: An xprv wallet already in storage that was imported from a
+  non-master key is detected from the depth of its stored `xpub`, explained in
+  the wallet list, and blocked from signing, sending and private-key export
+  instead of throwing on the send screen
+  ([#234](https://git.eeqj.de/sneak/AutistMask/issues/234)).
 - 2026-08-12: An unreported `holders_count` is now parsed as `null` rather than
   `0`, so the low-holder rule declines to judge an unknown count instead of
   hiding a legitimate token as spam, in both the transaction history and the