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/inc/routes/collab-locks.php

@@ -20,6 +20,13 @@ function collabLocksIsMember(PDO $db, string $bucketUid, int $tenantId): bool {
 
 // ── POST: acquire/refresh ────────────────────────────────────────
 
+// Maximum time a single holder can keep refreshing the same lock. Without a
+// cap a malicious member could heartbeat forever, blocking every other
+// member's writes. 10 minutes is long enough for any real edit session and
+// short enough to time-box grief. When the cap is hit the lock is force-
+// released and the client must re-acquire — giving everyone else a window.
+const COLLAB_LOCK_MAX_HOLD_SECONDS = 600;
+
 if ($route === '/api/collab-locks' && $method === 'POST') {
     if (!$clientTenant) jsonResponse(['error' => 'unauthorized'], 401);
     if (isRateLimited($db, 'collab-locks-post', 240)) jsonResponse(['error' => 'rate limited'], 429);
@@ -35,8 +42,12 @@ if ($route === '/api/collab-locks' && $method === 'POST') {
     // narrow window between cleanup and this query.
     $db->prepare("DELETE FROM collab_card_locks WHERE bucket_uid = :b AND card_uid = :c AND expires_at <= datetime('now')")
         ->execute(['b' => $bucketUid, 'c' => $cardUid]);
+    // Also drop locks that have been refreshed past the max hold window —
+    // cap enforcement for grief prevention.
+    $db->prepare("DELETE FROM collab_card_locks WHERE bucket_uid = :b AND card_uid = :c AND acquired_at <= datetime('now', '-" . COLLAB_LOCK_MAX_HOLD_SECONDS . " seconds')")
+        ->execute(['b' => $bucketUid, 'c' => $cardUid]);
     // Existing live lock? If a different tenant holds it, refuse.
-    $cur = $db->prepare('SELECT holder_id, holder_username, expires_at FROM collab_card_locks WHERE bucket_uid = :b AND card_uid = :c');
+    $cur = $db->prepare('SELECT holder_id, holder_username, expires_at, acquired_at FROM collab_card_locks WHERE bucket_uid = :b AND card_uid = :c');
     $cur->execute(['b' => $bucketUid, 'c' => $cardUid]);
     $existing = $cur->fetch();
     if ($existing && (int)$existing['holder_id'] !== (int)$clientTenant['id']) {