refactor(js): extract crypto module from app.js monofile (§3.1 start)

First slice of the app.js split. Approach: ordered classic-script files
loaded via separate <script> tags (argon2.js → app.crypto.js → app.js),
NOT ES modules / a bundler. Classic scripts share one global lexical
environment, so consts/functions cross-reference across files exactly as
in the monofile — zero call-site rewrites, near-zero risk. Chosen over the
audit's esbuild/ES-module suggestion because the code is written entirely
in global scope (functions call each other by bare name everywhere).

- js/app.crypto.js: KDF (PBKDF2 + Argon2id), verifier, AES-GCM encrypt/
  decrypt, key persist/restore. Verified byte-for-byte identical to the
  original block before removal; no duplicate const across the two scripts.
- index.html + BuildAssets whitelist + test harness updated for the load
  order. Harness CONCATENATES app.crypto.js + app.js (node:vm doesn't share
  top-level const across separate runInContext calls the way browsers share
  it across <script> tags); argon2.js stays a separate IIFE.
- Runtime-validated: rebuilt exe unlocks via quick-unlock and loads/decrypts
  entries — the extracted crypto (restoreCryptoKey, verifierFromKeyHex,
  decryptPwd) works from the separate file. 42/42 tests green.
- Docs: CLAUDE.md "Découpage frontend" (pattern + rules), file map, tests
  README, CODE_AUDIT §3.1.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

js/tests/README.md

@@ -18,12 +18,16 @@ Zero dependencies — uses the Node built-in test runner (`node:test`) and
 
 ## How it works — `harness.js`
 
-`app.js` is a ~12k-line browser monofile with **no module exports** and one
-top-level side effect (a `DOMContentLoaded` listener). The harness loads the
-file's source into a `node:vm` context with browser globals stubbed
+The frontend is a large browser script with **no module exports** and one
+top-level side effect (a `DOMContentLoaded` listener). It's being split into
+ordered classic-script files (§3.1); the harness **concatenates** the app
+parts in load order (`APP_PARTS` = `app.crypto.js` + `app.js`) into one
+source — node:vm doesn't share top-level `const`/`let` across separate
+`runInContext` calls the way the browser shares them across `<script>` tags.
+`argon2.js` is a self-contained IIFE and loads separately first. The
+concatenated source runs in a `node:vm` context with browser globals stubbed
 (`crypto`, `localStorage`, `document`, `location`, …) so `init()` never
-fires, then appends an export epilogue that surfaces the internals on
-`globalThis.__test`.
+fires, then an export epilogue surfaces the internals on `globalThis.__test`.
 
 Two gotchas the harness works around, both documented inline: