fix: WALLET-1364 — close the P3 residual

[ost-ptk]

Closes the six residual P3 defects recorded in WALLET-1364. #1465 — which introduced the
runKeysDownload extraction this branch builds on — is merged, so this now sits directly on
develop.

Jira: https://make-software.atlassian.net/browse/WALLET-1364

What each change removes

#	Defect	What the user experienced
10	Account mutations waited out the re-encrypt debounce	A browser quit or MV3 worker kill inside the 500 ms window dropped the last vault mutation. When that was an imported account, the secret key was gone — it exists nowhere else. The four account-mutating actions now persist immediately via takeEvery; everything re-derivable or cosmetic stays debounced.
11	A failed password change looked exactly like a successful one	navigate(Home) sat outside both worker callbacks and ran unconditionally. The user landed on Home believing their password had changed when it had not. Navigation now happens only on a successful worker result; a failure shows a field error and stays put.
12	Unlock worker errors said nothing	Both error paths stopped the spinner with no message — indistinguishable from a wrong password, which the same screen reports properly a few lines above.
13	A partial key archive was presented as success	Accounts whose createAsymmetricKeys returned secretKey: null were silently omitted from the zip while Success was shown. Now the export fails loudly, before anything is written to disk, and logs a count only.
14	Password hash compared with ===	Short-circuits at the first differing character. Now a constant-time comparison over the decoded bytes.
16	Non-Chrome style-src had no 'self'	A source list of only 'unsafe-inline' matches no external stylesheet, and every app template links /assets/fonts/fonts.css. Fixed in webpack.config.js and in Safari's hand-maintained runtime CSP in src/utils.ts, which had drifted the same way.

Item 15 (QR sync uses AES-CBC with no MAC) is deliberately not fixed — see below.

What the review round changed

Three findings, all confirmed against the code before acting on them. The first was the important
one: it meant items 11 and 12 were not actually delivered.

onerror could not fire for the failures it was added to report. Every worker in this repo is
written onmessage = async with no try/catch, so anything that throws inside — encodePassword,
deriveEncryptionKey, decryptVault's GCM tag check, encryptVault's missing-vault guard —
becomes a rejected promise, and a rejection inside a worker raises no error event on the parent
Worker. Only a script load failure reaches onerror. In change-password that was worse than
the bug it replaced: isSubmitting was cleared only inside onerror, so a rejected worker left the
button disabled on Loading forever, with no message and no navigation. Before this PR the user at
least left the page.

Failures now travel as a message. src/background/workers/types.ts holds the contract —
{ error: true } with no payload (the error object stays in the worker's console rather than
reaching the UI), plus WorkerResult<T> and an isWorkerError guard. Each worker wraps its body;
each page branches on the guard. onerror is kept for the script-load case it does cover.

The defect was wider than this PR's diff. generate-sync-wallet-qr-data-worker.ts has the same
shape and the same dead onerror, and it can throw for real — scryptAsync, PublicKey.fromHex on
a corrupt imported key. Worse, generateQRCode was async but resolved as soon as the worker was
constructed, so the .catch that PasswordProtectionPage already wraps onClick in was
unreachable and the page span forever. It now returns a promise that resolves when the QR data
exists and rejects on failure. The cipher is untouched — this is delivery of the failure, not the
format; item 15 below still stands.

password-protection-page had to be pulled in. It consumes the same verify-password worker, and
without handling { error: true } a worker failure would have destructured isPasswordCorrect: undefined and read as a wrong password — dispatching loginRetryCountIncremented(), burning a
login attempt and eventually locking the wallet. That would have been a new bug, not a leftover. Its
own onerror is no longer silent either, which closes a parity gap this description previously left
open.

The change-password worker outlived its page. It was never terminated and there was no unmount
cleanup, while the back link stays live throughout — only the submit button is disabled. Pressing
back during the worker's ~1-2 s of scrypt still committed the rotation from a stale closure, so the
user's next unlock with the old password would fail. React-router does not stop the navigate that
follows either: in the installed 7.18.2, activeRef.current = true is set in a layout effect with no
cleanup, so the post-unmount guard passes. The worker is now held in a ref and terminated on unmount,
and both callbacks check a mounted flag. The back link stays enabled — cancelling mid-scrypt now
genuinely cancels. unlock-vault was also spawning two workers per submit and terminating neither;
it now disposes them.

The constant-time comparison was unwireable without turning anything red. constantTimeEqualHex
was tested thoroughly in isolation, but nothing observed that verifyPasswordAgainstHash routed
through it — its three tests assert only correct → truthy and wrong → falsy, which plain ===
satisfies identically. Reverting the call site left the suite green. An upper-case hash is the one
input where the two differ, and that assertion is now in the suite.

Two things an earlier review found

A watch account used to break the whole export. Watch accounts are stored with secretKey: ''
and no hardware flag, so they passed the export list's !account.hardware filter. Item 13's
fail-loudly rule then meant a user with three real accounts and one watch account got no archive
at all. That is worse than the bug being fixed, so the export list now excludes accounts with
nothing to export (selectVaultAccountsAvailableForExport), and the hard failure is reserved for a
genuinely unexpected null — data corruption, which should still never be shown as success.

Change-password now waits for the worker, so it needed a submitting state. Navigation correctly
moved inside the success path, which leaves the page on screen for the worker's two scrypt passes
(N=2¹⁸, roughly 1-2 s). Without a guard, two taps spawn two ~256 MB scrypt workers in the popup.
It now mirrors the isSubmitting pattern already used by password-protection-page.

Limitations, stated rather than buried

• The constant-time property is not test-enforceable here. Mutating the loop to break on the
  first mismatch does not change the output — |= is monotonic — only the timing. What the tests now
  prove is that the comparison is correct and that the call site routes through it; the in-code
  comment is still the only thing standing between a future edit and a reintroduced short-circuit.
• The React paths have no automated coverage. This project's jest runs
  testEnvironment: 'node' with no jsdom, so change-password, unlock-vault,
  password-protection-page and wallet-qr-code cannot be unit-tested. Code reading was the only
  verification. Items to click through are listed below. The workers themselves are covered —
  see src/background/workers/workers.test.ts, which drives all four through a stubbed
  globalThis.onmessage/postMessage.
• change-password disables the submit button while the worker runs, but unlike its sibling
  password-protection-page it does not also guard Enter re-submission or make the field
  read-only. The button guard covers the double-tap vector; the parity gap is noted rather than
  closed here.
• The string Something went wrong. Please try again. has no catalogue entry, so the eight
  non-English locales fall back to English. locale:extract_pot was deliberately not run — lang/
  is hundreds of msgids behind and regenerating it would swamp this diff. A shorter
  Something went wrong already exists in four places; consolidating is a reasonable follow-up.

Why item 15 is not here

generate-sync-wallet-qr-data-worker.ts still uses AES-CBC with no MAC. The format is a
cross-application contract: casper-wallet-mobile/src/utils/aes/index.ts decrypts it with
aes-256-cbc and identical scrypt parameters (N = 2¹⁸, r = 8, p = 1, dkLen = 32), and its
react-native-aes-crypto exposes CBC only. Changing the extension alone breaks wallet sync until a
matching mobile release ships. The residual risk is also narrow — the ciphertext travels from the
user's own screen to their own camera. If picked up, it needs a versioned envelope landed on mobile
first. The review round touched this worker's error delivery only; the ciphertext it produces is
byte-for-byte what it was.

Please verify before merging

The CSP change needs a real browser, which is the one thing this branch cannot settle itself:

1. npm run build:firefox, load build/firefox via about:debugging, open the popup and the
   onboarding page, and check the console for a blocked-stylesheet violation on fonts.css —
   before and after. Same for the Safari build.
2. Change password: confirm it lands on Home only after the worker finishes, and that the button is
   disabled while it runs. Then start a change and press back during the scrypt pass — the old
   password must still unlock afterwards.
3. Unlock with a wrong password — the message must still be the wrong-password one, not
   Something went wrong.
4. Sync wallet QR — confirm the happy path still produces a scannable code, since its page function
   was promisified.
5. Export keys with a watch account present, using "select all" — the watch account should not be
   offered at all.

npm run ci-check is green: 94 suites, 903 tests.

[Comp0te]

Reviewed the six residual fixes against the flows they touch. The comments cluster on the two items that moved work into worker callbacks: the new onerror handlers can't fire for the failures they were added to report, and the change-password page now outlives its worker without owning it. One more is about the constant-time comparison being unwired-able at its call site without turning anything red. The CSP and export changes read as sound, and the item-15 rationale is convincing as written.