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

[ncw1992120]

What

Fixes #558 — WebChat channel session isolation.

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 — channel isolation was entirely lost (sessions cross-leaked in listSessions, collided on the UNIQUE constraint, etc.).

Fix

Embed the stable channel DB id (channel.getId()) into the conversationId instead, and keep pre-fix sessions visible via read-time fallback:

• deriveConversationId(Long channelId, ...) — new format webchat:<channelId>:<visitor>[:<session>]; hash-folding adapts to channelId length to stay within VARCHAR(64).
• legacyConversationId(apiKey, ...) — preserves the old key8 derivation purely for resolving existing webchat:mc_webch:... rows. Never used to mint new ids.
• resolveSessionConversationId(...) — prefers the current id, falls back to legacy if absent, else returns current (new sessions always get the new format).
• loadVisitorSessions matches both the channel and legacy prefixes; recoverSessionId parses against both bases, so legacy sessions stay listable/readable.
• Adds ConversationService.conversationExists for the resolver.

Already-collided legacy rows cannot be retroactively split and are left as-is. Pure code fix — no Flyway migration.

Tests

• Migrated all deriveConversationId(API_KEY, ...) call sites to channelId.
• New WebChatChannelIsolationTest — the core regression: two channels sharing an apiKey prefix + same visitor → each channel's listSessions returns only its own sessions.
• New WebChatLegacySessionCompatTest — seeds a legacy webchat:mc_webch:... session → still listable and its messages still readable (fallback path).
• Full WebChat* suite green (111 tests, 0 failures).

[ncw1992120]

Update — closed the legacy cross-channel leak found in adversarial review

The first commit's read-time fallback still leaked legacy sessions across channels: the legacy prefix webchat:mc_webch: is identical for every channel (all generated keys share the 8-char slice mc_webch), and username doesn't encode the channel either — so channel A's listSessions matched channel B's legacy sessions for the same visitor. Reproduced by a failing isolation test before the fix.

Root fix (commit 2, 9b76fff1): persist the owning channel on each webchat row.

• Flyway V171 (h2/mysql/kingbase): channel_id BIGINT NULL on mate_conversation. No inline backfill — pre-fix rows can't be reliably reconstructed.
• getOrCreateWebchatConversation carries channelId (written on insert); chatStream + createSession now pass channel.getId().
• listWebchatConversations(username, channelId) filters channel_id = ? OR channel_id IS NULL at the DB — channel-scoped rows are isolated exactly.
• loadVisitorSessions accepts channel_id-present rows directly; only NULL (pre-fix) rows fall through to the legacy-prefix in-memory match.

Documented limitation (tested): pre-fix collided rows (channel_id NULL, shared legacy cid) remain visible across the channels that collided — this is unrecoverable dirty data, not a regression. New sessions are strictly isolated.

WebChatChannelIsolationTest now seeds channel_id-persisted rows and asserts channel B's session does NOT appear in channel A's listing (the exact regression the first commit failed), plus a shared-legacy row that correctly stays visible to both.

Full WebChat* suite green: 114 tests, 0 failures.

[ncw1992120]

Superseded by #562, which adopts the same approach as the merged IM-channel fix e294b325 (scope conversationId by channel.getId(), no channel_id column). This PR's channel_id + read-time-fallback approach introduced a cross-channel leak in the legacy-prefix path; #562 avoids it entirely by following e294b325's posture (no legacy fallback).