Please address the comments from this code review:

## Overall Comments
- The new JSON parsing logic for `key`/`labels` is duplicated in several places (`getMessage`, `getOriginalMessage`, `updateMessagesReadedByTimestamp`, `updateChatUnreadMessages`, Chatwoot methods, etc.); consider refactoring these to consistently use the new `JsonQueryHelper` to reduce repetition and avoid subtle differences in JSON handling.
- The switch from single SQL UPDATE/COUNT operations to `findMany` + per-row application filtering in `updateMessagesReadedByTimestamp` and `updateChatUnreadMessages` may become very expensive as the `Message` table grows; it would be good to constrain these queries (e.g. paging with limits like you did elsewhere, or narrowing the WHERE clause further) so they don’t scan large portions of the table on each call.
- The new `addLabel`/`removeLabel` implementations rely on `chatId` and no longer upsert by `(instanceId, remoteJid)` like the previous raw SQL did, and they silently return if the chat doesn’t exist; if callers previously relied on the upsert semantics or remoteJid uniqueness, you may want to reintroduce those guarantees or at least make the behavior change explicit.

## Individual Comments

### Comment 1
<location> `src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts:525-534` </location>
<code_context>
+      const cacheKey = `message_${key.id}`;
</code_context>

<issue_to_address>
**🚨 issue (security):** Cache keys and search scope ignore instanceId and may return wrong messages across instances, plus pagination can miss older messages.

Because the cache keys don’t include `instanceId`, message IDs from different tenants will share the same key and can return another tenant’s message. The paginated scan also hard-stops after 10,000 rows, so older messages with the same `key.id` become undiscoverable, which regresses from the previous targeted query. Please namespace cache keys with `instanceId` and tighten the DB lookup (e.g., JSON-aware helper or provider-specific condition) instead of paging the full history with a hard `maxPages` cutoff.
</issue_to_address>

### Comment 2
<location> `src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts:537-546` </location>
<code_context>
-            pollCreationMessage: webMessageInfo[0].message?.pollCreationMessage,
-          };
+      while (pageNumber < maxPages) {
+        const messages = await this.prismaRepository.message.findMany({
+          where: { instanceId: this.instanceId },
+          skip: pageNumber * pageSize,
</code_context>

<issue_to_address>
**issue (performance):** Updating read status now performs per-row updates in application code and can be very expensive for large instances.

Previously this was a single SQL `UPDATE` with all filtering handled in the DB. The new approach loads all candidate messages into memory and performs one `update` per message, which can result in thousands of round trips and high data transfer on large instances. Please move as much filtering as possible back into the DB (even if that requires provider-specific JSON handling or helpers) and use bulk update semantics (`updateMany` or equivalent) instead of per-message updates.
</issue_to_address>

### Comment 3
<location> `src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts:4886-4895` </location>
<code_context>
+  private async addLabel(labelId: string, instanceId: string, chatId: string) {
</code_context>

<issue_to_address>
**issue (bug_risk):** Label add/remove now silently no-op when the chat is missing and also change the `where` semantics and storage format.

The previous raw SQL upserted the chat row (conflict on `(instanceId, remoteJid)`), but the new logic returns early when `chat` is missing, so labels will no longer be created for new chats. Also, the lookup uses `{ id: chatId, instanceId }` while the update uses only `{ id: chatId }`, weakening the constraint. Finally, `labels` is now always `JSON.stringify(labels)`, which may double-encode if the column is already JSON/array. Please (a) retain upsert behavior if still required, (b) consistently filter by both `id` and `instanceId`, and (c) avoid double-encoding `labels` for JSON/array columns.
</issue_to_address>

### Comment 4
<location> `src/api/services/channel.service.ts:745-754` </location>
<code_context>
-            pollCreationMessage: webMessageInfo[0].message?.pollCreationMessage,
-          };
+      while (pageNumber < maxPages) {
+        const messages = await this.prismaRepository.message.findMany({
+          where: { instanceId: this.instanceId },
+          skip: pageNumber * pageSize,
</code_context>

<issue_to_address>
**suggestion (performance):** The new chat listing implementation loses contact metadata and uses an unbounded message scan.

This change no longer joins `Contact` to derive `pushName`/`profilePicUrl`, and instead uses `chat.name`/`null`, which alters the API output—please confirm this is intentional. Also, `Message` rows are scanned for the entire instance (just time-filtered) and then grouped in memory; for large datasets this will be expensive. Consider restricting the query to `remoteJids` present in `chats`, or using `JsonQueryHelper.groupByJsonValue` (or similar) with a tighter `where` to avoid full-table scans.
</issue_to_address>

### Comment 5
<location> `src/api/integrations/chatbot/chatwoot/services/chatwoot.service.ts:1627-1636` </location>
<code_context>
-            messageContextInfo: { messageSecret },
-            pollCreationMessage: webMessageInfo[0].message?.pollCreationMessage,
-          };
+      while (pageNumber < maxPages) {
+        const messages = await this.prismaRepository.message.findMany({
+          where: { instanceId: this.instanceId },
</code_context>

<issue_to_address>
**issue (bug_risk):** Paging over messages without `orderBy` and scanning up to 10k rows to match a single key id is fragile and inefficient.

In `saveChatwootMessageIdsOnMessage`, `findMany` uses `skip`/`take` without an `orderBy`, so pagination is non-deterministic and pages can overlap or skip rows depending on the DB. It also scans up to 10,000 messages to locate a single `key.id`, which is expensive. `getMessageByKeyId` has the same issue and may miss the target by only checking 100 rows. Consider querying `key` directly via a JSON-aware condition (provider-specific or via a helper), or at least adding a stable `orderBy` (e.g., `id` or `messageTimestamp`) and avoiding arbitrary row caps when searching for a specific message.
</issue_to_address>

### Comment 6
<location> `.env.postgres:58` </location>
<code_context>
429683C4C977415CAAFCCE10F7D57E11
</code_context>

<issue_to_address>
**security (generic-api-key):** Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

*Source: gitleaks*
</issue_to_address>

### Comment 7
<location> `.env.mysql:58` </location>
<code_context>
429683C4C977415CAAFCCE10F7D57E11
</code_context>

<issue_to_address>
**security (generic-api-key):** Detected a Generic API Key, potentially exposing access to various services and sensitive operations.

*Source: gitleaks*
</issue_to_address>