#16689: browser: support multiple Chrome extension connections to relay

## Summary The extension relay previously accepted only one WebSocket connection from a Chrome extension at a time, rejecting subsequent connections with HTTP 409. This prevented users with multiple Chrome profiles (e.g. personal + work) from using the relay simultaneously. ## Changes ### Multi-extension relay (`extension-relay.ts`) - Replace single `extensionWs` with a `Map<string, ExtensionConnection>` keyed by random ID - Each extension tracks its own pending commands, targets, and session ownership - CDP commands are routed to the correct extension based on which one owns the target `sessionId` - When an extension disconnects, only its targets are cleaned up — other extensions remain unaffected - CDP clients are only disconnected when ALL extensions disconnect - `/extension/status` now returns `extensionCount` alongside `connected` ### WhatsApp config schema (`zod-schema.providers-whatsapp.ts`) - Add `triggerPrefix` and `syncFullHistory` to both `WhatsAppAccountSchema` and `WhatsAppConfigSchema` - These keys are read at runtime but were missing from the Zod strict schema, causing config validation to reject them ## Testing - All 4 existing `extension-relay.test.ts` tests pass - Manually verified two simultaneous WebSocket connections from different Chrome profiles - Verified CDP command routing to correct extension based on session ownership <!-- greptile_comment --> <h3>Greptile Summary</h3> Replaces the single-extension Chrome relay model with multi-extension support, allowing multiple Chrome profiles to connect simultaneously. Each extension connection is tracked independently with its own pending commands, session ownership, and cleanup lifecycle. CDP commands are routed to the correct extension based on session ownership. The WhatsApp config schema is also updated to include `triggerPrefix` and `syncFullHistory` fields that were already used at runtime but missing from the strict Zod validation schemas. - Multi-extension relay architecture uses a `Map<string, ExtensionConnection>` keyed by random ID, with a `sessionOwner` map for CDP session-to-extension routing - Per-extension cleanup on disconnect removes only that extension's targets and notifies CDP clients; CDP clients are only disconnected when ALL extensions disconnect - `/extension/status` now returns `extensionCount` alongside `connected` - WhatsApp schema fix adds missing `triggerPrefix` and `syncFullHistory` to both `WhatsAppAccountSchema` and `WhatsAppConfigSchema` <h3>Confidence Score: 4/5</h3> - This PR is safe to merge; the multi-extension refactor is well-structured and the WhatsApp schema fix is straightforward. - The architectural change from single to multi-extension support is logically sound. Session ownership routing, per-extension cleanup, and fallback logic are all implemented correctly. The existing 4 tests pass, and the WhatsApp schema changes are a simple, necessary fix for runtime fields missing from strict validation. No critical logic bugs, security issues, or regressions found. Deducted one point because the existing test suite doesn't cover multi-extension scenarios (e.g., two simultaneous extensions, session routing between them, one disconnecting while another remains), relying on manual verification for the core new functionality. - No files require special attention. _{Last reviewed commit: dc1c1d9} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->