fix(webchat): scope conversationId by channel id (#558)

[ncw1992120]

What

Fixes the WebChat side of #558 — channel session isolation. Companion to the IM-channel fix in e294b325 (already on dev), using the same approach.

The bug: deriveConversationId identified a channel by the first 8 chars of its apiKey. All generated keys share the 11-char prefix mc_webchat_, so that slice was the constant mc_webch for every channel. Two channels with the same visitorId derived the same conversationId, collapsing their sessions together (cross-leak in listSessions, UNIQUE collisions).

Fix

Scope the conversationId by channel.getId() (the stable DB primary key), mirroring e294b325:

• deriveConversationId(Long channelId, ...) — format webchat:<channelId>:<visitor>[:<session>]
• The VARCHAR(128) widening from V171 (e294b325) means the hash-folding branch is no longer needed — removed, simplifying the derivation
• loadVisitorSessions filters by the channel-scoped prefix webchat:<channelId>: exactly

No channel_id column, no read-time legacy fallback, no new migration — consistent with e294b325's posture. Pre-fix sessions keyed by the old mc_webch prefix are not migrated (same as the IM fix: old sessions are not carried forward).

Tests

• New WebChatChannelIsolationTest — the core regression: two channels sharing an apiKey prefix + same visitorId → each channel's listSessions returns only its own sessions (channel B's session does NOT appear in channel A).
• Migrated all deriveConversationId call sites to channelId.
• Full WebChat* suite green (106 tests, 0 failures).

Relationship to PR #561

This supersedes #561, which used a channel_id column + read-time fallback. That approach introduced a cross-channel leak in the legacy-prefix fallback. This PR adopts e294b325's simpler, proven approach instead. #561 should be closed.