fix: one wording for a rejected password on every screen (closes #172)

The send confirmation and the delete-wallet confirmation rendered
"Wrong password." — a fragment, which README Language & Labeling and
RULES.md:120 both forbid — while the two reveal screens said "That
password is not correct." and the two dApp approval paths said "That
password is incorrect." Three wordings for one condition, on screens a
user can reach minutes apart.

All five decryptWithPassword call sites now show the wording the
approval paths introduced:

    That password is incorrect. Please try again.

Strings only. Nothing about how a wrong password is handled changes: it
still fails closed on every screen, and the approval paths' settlement,
claim/release interlock and retry behaviour are untouched.

The new test scans the source for the call sites rather than driving
each view, because the invariant is about the set: a sixth screen that
decrypts the vault has to join it, and a per-view test cannot notice a
screen nobody wrote one for.

TODO.md

@@ -44,6 +44,14 @@ undefined identifiers, which is how
 
 # Completed Steps
 
+- 2026-08-12: One wording for a rejected password on every screen that asks for
+  one — the send confirmation and the delete-wallet confirmation no longer say
+  "Wrong password." (a fragment, which `RULES.md` Language & Labeling forbids)
+  and the two reveal screens no longer say "not correct", so all five
+  `decryptWithPassword` call sites now show the sentence the dApp approval paths
+  introduced. Strings only, no behaviour change, and each error container
+  measured at a 360px viewport in the pinned Playwright container
+  ([#172](https://git.eeqj.de/sneak/AutistMask/issues/172)).
 - 2026-08-12: The dust threshold field now explains a rejection instead of
   snapping back in silence, with the parse in a pure, unit-tested module that
   accepts plain decimal digits only — hex and exponent notation are refused