security: v2.0 — AES-GCM crypto, SSRF guards, rate limits, hardening

Breaking wire-format change: dual-read (V1+V2) / single-write (V2) so
existing user secrets, stored messages, and inter-tenant key keep
working. Old clients and relays lose cross-version chat until both
sides are upgraded.

Relay
- Switch clientEncrypt/masterEncrypt to AES-256-GCM with HKDF-derived
  per-ciphertext salts; keep CBC-V1 fallback on decrypt only.
- On-bootstrap migration re-envelopes tenant secret_encrypted and the
  inter-tenant key to GCM-V2 (idempotent).
- CORS: stop reflecting arbitrary Origin; allow own origin + optional
  RELAY_CORS_ORIGINS env allowlist; drop Access-Control-Allow-Credentials.
- Generic error messages replace "no such user: <name>" enumeration.
- Exception messages no longer echoed back; logged server-side.
- Collab-lock max hold capped at 10min so a member can't grief-refresh
  forever.
- Attachment filenames validated against hex.<ext> pattern.
- Passwords min length 10; /api/account/password rate-limited.

App / Electron client
- Shared hyprcrdRelayEncrypt/Decrypt helpers (GCM-V2 write, V1 read).
- Chat + collab-buckets plugins delegate to the shared helpers.
- Poll + push + attachments migrated to the dual-format path.
- /api/relay/settings GET returns has_key boolean; secret never echoed.
- Setup endpoint now CSRF-checked.
- SSRF: CURLOPT_PROTOCOLS restricted to HTTP(S) everywhere; bookmarks
  favicon fetch also blocks private/loopback/link-local.
- Login / password-change rate limiter moved to DB-backed IP keying.
- Passwords min length 10 throughout.
- Zip import enforces per-file (25MB) and total (500MB) caps, extension
  allowlist, no-overwrite.
- Verbose relay-push debug gated behind APP_DEBUG env.

Version bumped to 2.0.0 (protocol-breaking).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

relay/index.php

@@ -40,10 +40,25 @@ $isSetup = tenantCount($db) === 0;
 
 if (str_starts_with($route, '/api/')) {
     header('Content-Type: application/json');
+    // CORS: the hyprcrd client hits us server-side (no browser CORS in play)
+    // and the relay UI lives same-origin, so the only legitimate cross-origin
+    // callers are other tenant UIs on the same relay host. We allow the
+    // relay's own scheme+host, plus an opt-in allowlist via RELAY_CORS_ORIGINS
+    // (comma-separated). Credentials are intentionally NOT allowed — API auth
+    // is header-based (X-Relay-User/Key) and the UI is same-origin.
     $origin = $_SERVER['HTTP_ORIGIN'] ?? '';
-    if ($origin) {
+    $ownScheme = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') || ($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https' ? 'https' : 'http';
+    $ownOrigin = $ownScheme . '://' . ($_SERVER['HTTP_HOST'] ?? '');
+    $allowed = [$ownOrigin];
+    $extra = getenv('RELAY_CORS_ORIGINS');
+    if ($extra) {
+        foreach (explode(',', $extra) as $o) {
+            $o = trim($o);
+            if ($o !== '') $allowed[] = $o;
+        }
+    }
+    if ($origin && in_array($origin, $allowed, true)) {
         header('Access-Control-Allow-Origin: ' . $origin);
-        header('Access-Control-Allow-Credentials: true');
         header('Vary: Origin');
     }
     header('Access-Control-Allow-Headers: Content-Type, X-Relay-User, X-Relay-Key');