fix: re-enable Confirm Delete after a delete, so a second one needs no reopen (closes #335)

The password route disabled its Confirm Delete button before the decrypt
and never re-enabled it on success, so a second delete in the same popup
session found a dead button until the popup was closed and reopened. The
lost-password route re-enabled its own button in its leave hook, so the
two screens on the one screen behaved differently.

Both routes now reset the button through the shared finishDelete(), the
one path they both take, and the lost-password leave hook no longer
handles it separately. Tests drive a password-route delete and a second
delete in the same session; they fail against the prior head, where the
button stays disabled after the first delete.

Model: opus-4-8

TODO.md

@@ -132,6 +132,17 @@ but the review is broader than any of them.
   constant rather than `isDebug()`, so it survives only in a debug build; a
   testnet or the runtime debug toggle still raises the banner but without the
   view id.
+
+- 2026-09-21: The Confirm Delete button on the delete-wallet screen no longer
+  stays dead after a successful delete
+  ([#335](https://git.eeqj.de/sneak/AutistMask/issues/335)). The password route
+  disabled the button before the decrypt and never re-enabled it, so a second
+  delete in the same popup session needed a reopen; the lost-password route
+  re-enabled its own button in its leave hook, so the two screens behaved
+  differently. Both now reset through the shared `finishDelete()`, the one path
+  both routes take, so they behave the same and the button is live for the next
+  delete.
+
 - 2026-08-30: An address no longer wraps, or is shortened to fit, in any of the
   common views ([#380](https://git.eeqj.de/sneak/AutistMask/issues/380)). The
   wallet list was the reported case: the address shared one row with the