security: fix SAS verification bypass and unauthenticated frame injection; release v5.5.2

A security review of the transport and verification layers. Every item is a fix
to how untrusted peer input is handled; no features changed.

- SAS verification could be bypassed. `verification_both_confirmed` is an
  unauthenticated frame on a channel that is not yet trusted, but it was taken as
  proof that both sides had compared their codes — so a peer who completed the
  signalling exchange could send it right after the data channel opened and drive
  the other side to a "verified" session while the user never looked at the code.
  It is now only an acknowledgement: refused unless this side already confirmed
  locally, and _setVerifiedStatus() independently rejects any SAS-based
  transition without a local confirmation. Holding ECDH-derived keys was never
  proof of identity — a MITM has those too.

- Unauthenticated frames could be injected into the chat. A bare
  {type:"message"} frame, a raw non-JSON frame and a binary frame were each
  decoded and rendered, bypassing decryption, the HMAC check and the verification
  gate; the injected text was indistinguishable from a genuine message. Chat
  content now reaches the UI only through the authenticated enhanced_message
  path.

- A peer could supply the verification code. `sas_code` announcements were
  adopted verbatim when no local SAS had been derived yet. They may now only
  corroborate the locally derived code.

- Anti-replay never ran. The sequence-number and AAD validators were defined on
  SecureKeyStorage instead of the connection manager, so every call site failed
  with a TypeError and the sliding replay window was dead code. Moved onto the
  manager, wired into the live chat path, and a missing or non-numeric sequence
  number now fails closed instead of sailing through the range checks.

- File transfers are gated on verification in both directions. Control frames are
  written straight to the data channel by the transfer system; sending was
  already gated, receiving now is too.

- Tighter CSP: connect-src and img-src no longer allow arbitrary https: hosts
  (nothing in the app talks to a third party), plus base-uri 'none'.

- The SAS is no longer written to logs, and is compared in constant time on every
  path. Fixed SecureMasterKeyManager.isUnlocked() testing a field renamed long
  ago, so it never actually gated anything.

- Fixed the header showing "Secure undefined%": getRealSecurityLevel() became
  reachable for the first time by the move above and returned only per-feature
  booleans, while the header renders `level` and `score` directly. It now runs
  the same verified scoring as every other consumer.

Adds regression tests for the verification gate, inbound frame authentication and
the security-level shape.

tests/secure-chat-features.test.mjs

@@ -66,8 +66,10 @@ const T = EnhancedSecureWebRTCManager.MESSAGE_TYPES;
 // This is the path real chat uses (dataChannel.onmessage -> _processEnhancedMessageWithoutMutex).
 {
     const envelope = JSON.stringify({ type: 'message', data: 'hi there', meta: { mid: 'm7', once: true, ttl: 30 } });
+    // decryptMessage always returns the authenticated sequence number alongside
+    // the plaintext; the receive path uses it for anti-replay validation.
     globalThis.window.EnhancedSecureCryptoUtils = {
-        decryptMessage: async () => ({ message: envelope })
+        decryptMessage: async () => ({ message: envelope, messageId: 'msg_7', sequenceNumber: 0 })
     };
     const calls = [];
     const manager = {
@@ -76,6 +78,12 @@ const T = EnhancedSecureWebRTCManager.MESSAGE_TYPES;
         _checkInboundRateLimit: () => true,
         _sanitizeIncomingChatMessage: (m) => m,
         _sanitizeMessageMeta: P._sanitizeMessageMeta,
+        _validateIncomingSequenceNumber: P._validateIncomingSequenceNumber,
+        replayProtectionEnabled: true,
+        expectedSequenceNumber: 0,
+        replayWindow: new Set(),
+        replayWindowSize: 64,
+        maxSequenceGap: 100,
         onMessage: (message, type, meta) => calls.push({ message, type, meta }),
         deliverMessageToUI: P.deliverMessageToUI
     };