sec: gate super-admin invite minting, OCR settings, and alert mutations

Three findings from the branch security review:

1. HIGH — Privilege escalation via super-admin invite. POST
   /api/v1/admin/invitations was gated only by manage_users (held by the
   port-scoped director role). The body schema accepted isSuperAdmin
   from the request, createCrmInvite persisted it verbatim, and
   consumeCrmInvite copied it into userProfiles.isSuperAdmin — granting
   the new account cross-tenant access. Now the route rejects
   isSuperAdmin=true unless ctx.isSuperAdmin, and createCrmInvite
   requires invitedBy.isSuperAdmin as defense-in-depth.

2. HIGH — Receipt-image exfiltration via OCR settings. The route
   /api/v1/admin/ocr-settings (and the sibling /test) were wrapped only
   in withAuth — any port role including viewer could PUT a swapped
   provider apiKey + flip aiEnabled, redirecting every subsequent
   receipt scan to attacker infrastructure. Both are now wrapped in
   withPermission('admin','manage_settings',…) matching the sibling
   admin routes (ai-budget, settings).

3. MEDIUM — Cross-tenant alert IDOR. dismissAlert / acknowledgeAlert
   issued UPDATE … WHERE id=? with no portId predicate. Any
   authenticated user with a foreign alert UUID could mutate it. Both
   service functions now require portId and add it to the WHERE; the
   route handlers pass ctx.portId.

The dev-trigger-crm-invite script passes a synthetic super-admin caller
identity since it runs out-of-band.

The two public-form tests randomize their IP prefix per run so a fresh
test process doesn't collide with leftover redis sliding-window entries
from a prior run (publicForm limiter pexpires after 1h).

Two new regression test files cover the fixes (6 tests).

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

tests/integration/public-interest-trio.test.ts

@@ -18,12 +18,15 @@ vi.mock('@/lib/services/inquiry-notifications.service', () => ({
   sendInquiryNotifications: vi.fn().mockResolvedValue(undefined),
 }));
 
-// The rate-limiter is keyed by IP header and persists across requests inside a
-// single process. Use a unique IP per test call to avoid 429s.
+// The rate-limiter is keyed by IP header and is now redis-backed; entries
+// pexpire after the publicForm window (1h). Randomize the high octets so a
+// fresh test run doesn't collide with leftover redis state from a previous
+// run sharing the same redis instance.
+const IP_PREFIX = `10.${Math.floor(Math.random() * 200) + 10}`;
 let ipCounter = 1;
 function uniqueIp(): string {
   ipCounter += 1;
-  return `10.0.${Math.floor(ipCounter / 255) % 255}.${ipCounter % 255}`;
+  return `${IP_PREFIX}.${Math.floor(ipCounter / 255) % 255}.${ipCounter % 255}`;
 }
 
 describe('POST /api/public/interests — trio creation', () => {