fix: run libsodium on WebAssembly under the extension CSP (closes #182)

libsodium ships a WASM build and a wasm2js translation in one file, tries
WASM first, and silently falls back if instantiation throws. Under a plain
script-src 'self' the fallback was taken on every popup load, announced by
nothing but an uncaught CompileError.

Measured on the vault's own Argon2id parameters (OPSLIMIT_INTERACTIVE,
MEMLIMIT_INTERACTIVE), node 22: WASM 141-198ms per derivation, wasm2js
3204-3660ms. The work factor is identical either way — it is set by the
ops and memory parameters, not by wall time — so the fallback bought no
security and cost about 3.5s on every operation that asks for the
password, which is every signature.

Both manifests now declare script-src 'self' 'wasm-unsafe-eval';
object-src 'self' for extension pages: an object under
content_security_policy.extension_pages for Chrome MV3, a bare string for
Firefox MV2. The keyword permits compiling WebAssembly and nothing else —
not eval() of strings, not inline script, not remote script — and reaching
it requires already executing script in an extension page. 'unsafe-eval'
is not granted.

The silence is what made this dangerous, so the fallback is now loud at
three levels: tests/manifest.test.js pins both policies to exactly that
token set, failing make check if the grant is dropped or if anything is
added beside it; tests/vaultBackend.test.js asserts the unit tests
exercise the WASM backend, with a self-validating check that libsodium
never swapped its fallback in; and the e2e suite compiles a WebAssembly
module inside the real popup under the real manifest, with the harness
allowlist entry that used to excuse the CompileError now deleted.

The runtime fallback itself is kept — a wallet that refuses to decrypt is
worse than a slow one — but vault.js now reports the backend and logs an
error when it is not WASM.

tests/manifest.test.js

@@ -81,15 +81,12 @@ describe("shipped Content Security Policy", () => {
 
     // MV2 takes the policy as a bare string. Firefox does not require
     // 'wasm-unsafe-eval' for MV2 today — enforcement is report-only and
-    // Bugzilla 1770909 is still open — so this is future-proofing, not a
-    // mandate. It does not weaken anything under either baseline: Gecko's
-    // real MV2 default (extensions.webextensions.default-content-security-
-    // policy) is `script-src 'self' 'wasm-unsafe-eval';` with no object-src
-    // at all, so this string leaves script-src unchanged and ADDS
-    // object-src 'self', constraining <object>/<embed> sources that were
-    // previously unrestricted. Against MDN's documented MV2 default
-    // (`script-src 'self'; object-src 'self';`) it is a one-token loosening,
-    // identical to Chrome. Same policy, different manifest shape.
+    // Bugzilla 1770909 is still open — so that token is future-proofing
+    // for when it lands, not a mandate, and it stays inside Firefox's MV2
+    // base-CSP ceiling. object-src 'self' is the load-bearing half: a
+    // Firefox before 106 rejects an MV2 policy string that omits
+    // object-src and falls back to its own default, discarding everything
+    // declared here. Same policy as Chrome, different manifest shape.
     test("firefox MV2 allows WASM and nothing else beyond 'self'", () => {
         const csp = readManifest("firefox").content_security_policy;
         expect(typeof csp).toBe("string");