fix: let a user who lost the password delete the wallet, and warn before they can (closes #312)

Deleting a wallet was password-gated and importing its recovery phrase
again was refused as a duplicate xpub by findWalletByXpub(), so a user who
held the phrase but had forgotten the password could neither leave the
wallet nor come back to it. The only escape was clearing extension storage
through browser internals, which takes every other wallet with it, and
nothing in the product ever warned that this was possible.

DeleteWallet now offers "I have lost my password", a screen that destroys
the wallet after the user types its name back. No password: requiring one
to discard a secret protects nobody, because an attacker at the popup who
wants the wallet gone can uninstall the extension, so the only person such
a gate stops is the owner who forgot it. The typed name is a check that
the user knows which wallet they are on, so it is matched with surrounding
spaces and letter case ignored.

This is the deletion route rather than the re-import route, and only one
of the two. Re-import would have had to be built three times over (hd and
xprv by xpub, key by address), would make the user retype the recovery
phrase into a live popup in order to change a password, and reaches no end
state that delete-then-import does not already reach through the existing
import path and scanForAddresses().

Both routes share one finishDelete(), so the selection repair, the site
permission cleanup and the AUTISTMASK_ACTIVE_CHANGED broadcast cannot
diverge between them. The new screen is not in RESTORABLE_VIEWS, alongside
delete-wallet-confirm: a popup reopened by accident must not land on a
button that erases key material. It registers an onViewLeave() cleanup as
well, not because a wallet name is a secret but because a typed
confirmation left standing in a hidden view leaves a wallet one click from
deletion. The two delete screens are siblings, so nothing is pushed on the
way in and Back re-enters DeleteWallet through show(), which hands it back
its wallet selection.

AddWallet's password hint now states, per import mode, that the password
cannot be recovered or reset and names what the only backup is. The hint
line reserves its height so switching tabs cannot move the password fields
under the pointer.

The test drives the real view against a chrome.storage.local stub that
structured-clones on both set and get, and asserts against what comes back
out of storage rather than against the live state object, so it fails on
the deletion of saveState() and not only on an in-memory splice.

src/popup/index.html

@@ -160,15 +160,9 @@
                          Two things stop that: the three wordings in
                          PASSWORD_HINTS are kept within a couple of
                          characters of each other in length, and this floor
-                         matches what each of them needs. All three measure
-                         48px -- 3 lines at the 16px line height, at the
-                         368px width this box has in the 396px popup body.
-                         Do not raise it: the reserve is unused height on
-                         every tab, and at 6rem it pushed
-                         #btn-add-wallet-confirm to bottom=628px in a 600px
-                         viewport, below the fold. -->
+                         is above what the longest of them needs. -->
                     <p
-                        class="text-xs text-muted mb-1 min-h-[3rem]"
+                        class="text-xs text-muted mb-1 min-h-[6rem]"
                         id="add-wallet-password-hint"
                     >
                         This password encrypts your recovery phrase on this

src/popup/views/deleteWallet.js

@@ -26,17 +26,6 @@ function displayName(walletIdx) {
     return (wallet && wallet.name) || "Wallet " + (walletIdx + 1);
 }
 
-// What the typed confirmation and the wallet name are compared as. HTML
-// collapses runs of whitespace when it renders the name, so a wallet named
-// "My  Wallet" with two spaces DISPLAYS as "My Wallet": the user cannot
-// see the second space and cannot type a string that matches the stored
-// name. Comparing collapsed on both sides is what keeps the confirmation
-// satisfiable, on the one screen whose whole purpose is unwedging a user
-// who is already stuck. Case and surrounding space go the same way.
-function confirmKey(name) {
-    return name.trim().replace(/\s+/g, " ").toLowerCase();
-}
-
 // Drop the password from the DOM and the wallet selection from the
 // closure. Registered as the view-leave handler as well as run on entry,
 // so the typed password does not sit in the hidden view after the user
@@ -167,14 +156,13 @@ function init(_ctx) {
             return;
         }
 
-        // Case, surrounding spaces and repeated inner spaces are not part
-        // of the confirmation; see confirmKey(). This asks whether the
-        // user knows which wallet they are on; it is not a secret, and
-        // refusing "wallet 2" for "Wallet 2" would only teach the user to
-        // distrust the control.
-        const typed = $("delete-wallet-lost-name-input").value;
+        // Case and surrounding spaces are not part of the confirmation.
+        // This asks whether the user knows which wallet they are on; it is
+        // not a secret, and refusing "wallet 2" for "Wallet 2" would only
+        // teach the user to distrust the control.
+        const typed = $("delete-wallet-lost-name-input").value.trim();
         const expected = displayName(lostPasswordIndex);
-        if (confirmKey(typed) !== confirmKey(expected)) {
+        if (typed.toLowerCase() !== expected.toLowerCase()) {
             $("delete-wallet-lost-flash").textContent =
                 "That is not the name of this wallet. Type " +
                 expected +

tests/deleteWalletLostPassword.test.js

@@ -326,33 +326,6 @@ describe("the typed confirmation", () => {
         ]);
         expect(await persistedWallets(storage)).toHaveLength(2);
     });
-
-    // A name with a doubled inner space RENDERS with one — HTML collapses
-    // runs of whitespace — so the string the user can see and type is not
-    // the string the name is stored as. Comparing the two raw would make
-    // this wallet's confirmation impossible to satisfy by any typing at
-    // all, wedging the one screen that exists to unwedge people.
-    test("a doubled space inside the name is typed back as one", async () => {
-        const { deleteWallet, state, storage } = load();
-        state.wallets[1].name = "My  Wallet";
-        await openLostPassword(deleteWallet, 1);
-
-        // What the DOM was handed still has both spaces; what the user
-        // reads off the screen, and therefore types, has one.
-        expect(node("delete-wallet-lost-name").textContent).toBe("My  Wallet");
-        node("delete-wallet-lost-name-input").value = "My Wallet";
-        await click("btn-delete-wallet-lost-confirm");
-
-        expect(state.wallets.map((w) => w.name)).toEqual([
-            "Wallet 1",
-            "Wallet 3",
-        ]);
-        const persisted = await persistedWallets(storage);
-        expect(persisted.map((w) => w.encryptedSecret)).toEqual([
-            "secret-one",
-            "secret-three",
-        ]);
-    });
 });
 
 describe("deleting without the password", () => {