security: honest E2EE messaging + CSP hardening (Levers 1 & 2)

[jaschadub]

Implements the two cheap "be honest about browser-E2EE" levers: disciplined messaging + low-cost CSP hardening.

Lever 1 — honest messaging

• Drop "zero-knowledge" from the status bar. The web UI is end-to-end encrypted in your browser, but the same server ships the JS that does the encryption, so it isn't "zero-knowledge" in the strong sense. We shouldn't imply a guarantee we can't make.

• New FAQ entry — "Is the web UI 'zero-knowledge'?" — with a per-client threat matrix lifted from docs/security.md, and a pointer to the sndr CLI for security-critical transfers:

  Threat	Web UI	sndr CLI
  Reading file contents after a passive server/storage breach	✅	✅
  Reading filenames / sizes / types after a passive breach	✅	✅
  Network / TLS eavesdropper reading contents	✅	✅
  An actively malicious server serving targeted JS to steal the key	❌	✅
  The operator seeing IPs, file sizes, timing, or denying service	❌	❌

  This is also the honest-positioning differentiator vs. tools that brand their web client "zero-knowledge" while sharing the identical operator-JS limitation.

Lever 2 — cheap CSP hardening (server/routes/index.js)

• Remove a stray console.log that ran on every request inside the CSP connect-src callback.
• worker-src 'self' — the download service worker is same-origin.
• base-uri 'self' — blocks cross-origin <base> injection while still allowing the app's own same-origin base. (Caught and fixed a regression here: base-uri 'none' breaks the app, which sets its own base — see verification.)
• frame-src 'none' — the app embeds no nested browsing contexts.

Also

Fixes a broken CLI repo link tarnover/snder → tarnover/sndr in both the README reference and the new FAQ content.

Verification

Driven in production mode (NODE_ENV=production, CSP actually active — note config.env defaults to development, so this path isn't exercised by a plain dev run):

• CSP response header is well-formed with the new directives.
• App shell, nonce'd scripts/styles, the same-origin service worker (registers, scope /), and the How-it-works modal all load with zero CSP violations.
• Status bar confirmed to no longer contain "zero-knowledge"; honest footnote intact.
• npm test green (48 backend + 23 frontend).

Deliberately deferred (not cheap here — documented, not forgotten)

• SRI on script/style tags. Assets are served from 'self' via server-rendered tags reading the webpack manifest; SRI would need a build plugin + manifest/layout plumbing for marginal value on same-origin assets. Worth revisiting if assets ever move to a separate CDN.
• PWA service-worker bundle pinning.
• Pre-existing finding (not fixed here): with the container's own CSP active in prod mode, the app triggers a data:-URL fetch that connect-src blocks. It reproduces identically on master (connect-src is unchanged in this PR) and only surfaces under the ancient bundled puppeteer's uploadFile; real uploads use FileReader, no data: fetch. Deployment note: environments that front the container with nginx security headers (e.g. snd.dx.pe) must keep the nginx and app CSPs consistent — browsers enforce the intersection of multiple CSP headers, so an nginx base-uri 'none'/restrictive connect-src would override what the container sends.