fix(chatwoot): dedupe automation echoes in messages.upsert

[wahyuwidgetworks]

Summary

• Add a [WIDGET-WORKS] DB fallback in messages.upsert to detect messages already synced to Chatwoot by key and reuse existing Chatwoot IDs.
• Skip Chatwoot sync when a prior message with the same key already has chatwootMessageId (covers Chatwoot automation echoes), while keeping the upstream cache guard.
• Limit the fallback to Chatwoot-enabled, non-broadcast flows.

Testing

• Not run (logic-only dedupe guard).

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Scope Chatwoot dedupe lookup to current instance

The new Chatwoot dedupe fallback calls message.findFirst using only the message key id, without filtering by instanceId (lines 1195-1199). Earlier in the same handler the duplicate cache key is ${this.instance.id}_${received.key.id}, which suggests message ids are not considered globally unique across tenants. In a multi-instance deployment, a message id collision would cause this lookup to return another tenant’s Chatwoot record, set those Chatwoot ids on the incoming message, and skip eventWhatsapp, effectively dropping Chatwoot sync for the current instance and leaking conversation ids across tenants. The query should be constrained to the current instance to avoid cross-tenant contamination.

Useful? React with 👍 / 👎.