fix(api): stop resolving a contact's conversation and inbox arbitrarily

[sung17]

Summary

• The public /v1/contacts/{identifier}/messages handlers picked both their target conversation and their target ContactInbox without an ordering, so which one they got was left to Postgres. A wrong resolution failed asynchronously — the handler had already answered 204 — which is the silent-send shape reported in Comment-originated contacts cannot be messaged via API even after the contact replies (silent failure) #879.
• A contact holds a DM conversation plus one comment thread per post they commented on, so the same contact could resolve to a different conversation on two consecutive calls. The DM thread now wins, decided inside the lookup rather than behind a per-caller flag: with only the send path preferring it, an integrator could POST a message, get 204, then list the conversation and not find it. Send, list and get cannot drift because there is no flag to forget.
• contactInboxes[0] is gone. That relation is keyed by contactId, so it carries every inbox the contact has across every channel — an unordered [0] could address the wrong page entirely.

Whether this accounts for the failure rate measured in #879 is still unconfirmed, so this refs the issue rather than closing it.

Changes

• packages/business/src/conversation/service.ts

  • findByContactWithInboxes probes the DM conversation (sourceId IS NULL, a single hit on the unique Conversation_contactId_dm_key) before falling back. A contact who has only ever commented still resolves to their comment thread.
  • resolveContactInboxForSend resolves the ContactInbox via contactInboxService.findRecentByContactId, the same resolution resolveContactInboxForConversation already used. An explicit inboxId still wins.
  • Both orderings spelled as SQL with DESC NULLS LAST. lastActivityAt is nullable with no default, so a freshly created conversation holds NULL and a plain DESC would rank a never-active conversation above every real one. The { lastActivityAt: "desc" } object form cannot express the NULLS clause, and raw SQL reaches orderBy only through its callback form. This also matches Conversation_workspaceId_lastActivityAt_id_idx, declared .desc().nullsLast(). findLatestByContact carried the same latent bug and is fixed alongside.
  • Docstrings record why the channel is decided by the ContactInbox alone: a Conversation carries no inbox or channel column, and the single DM row a contact owns is shared across all their channels.

• packages/business/__tests__/conversation-find-by-contact-with-inboxes.test.ts (new) — DM-first probe, comment-thread fallback, and the NULLS LAST ordering.

• packages/business/__tests__/conversation-resolve-contact-inbox-for-send.test.ts — the case asserting the old contactInboxes[0] behaviour is replaced; the 404 paths now cover findRecentByContactId returning nothing.

Notes for reviewers

listMessages and getMessage are not touched: they call findByContactWithInboxes with no arguments and pick up the new behaviour automatically. That is deliberate — it is what makes the three endpoints agree by construction.

One behaviour change worth a second opinion: listMessages will no longer surface messages that live in a comment thread for a contact who also has a DM thread. Previously that was arbitrary, so it sometimes did. The endpoint has no parameter for choosing a thread; if that turns out to matter, the fix is to add a conversationId parameter rather than to go back to an arbitrary pick.

Test plan

• pnpm --filter @chatbotx.io/business test — 274 files, 3083 tests pass
• pnpm --filter builder test — 649 files, 5037 pass / 2 skipped
• pnpm --filter builder check-types
• pnpm lint
• Manual: for a contact with both a DM thread and a comment thread, POST /v1/contacts/{id}/messages, then GET the same path and confirm the message is listed