feat(engine): Baileys contacts/chats + read-receipts (slice 3b, final)

[rmyndharis]

Summary

Slice 3b — the final Baileys slice: un-gates getContacts/getContactById/getChats/resolveContactPhone/sendSeen/deleteChat, backed by a per-session in-memory store fed from Baileys events. After this, the Baileys engine implements every neutral IWhatsAppEngine capability it can meaningfully support.

Stacked on #309 (base feat/baileys-groups, itself stacked on #308 → #307 → #299). Diff is slice-3b only; the base retargets to main as the stack merges down.

What's added

• BaileysSessionStore (new, in-memory, no DB/DI) — per-session maps for contacts, chats, last-message-per-chat, and lid→phone, fed fire-and-forget from contacts.upsert/update, chats.upsert/update, messaging-history.set, and messages.upsert. Rebuilt on each connect's history sync; type-only Baileys imports keep it engine-neutral and unit-testable without a socket.
• getContacts/getContactById/getChats → mapped from the store to neutral Contact/ChatSummary. resolveContactPhone → best-effort via the id user-part / lidPnMappings / a contact's phoneNumber, else null.
• sendSeen(chatId) → readMessages([lastKey]) (false when no last message is known). deleteChat(chatId) → chatModify({ delete: true, lastMessages: [...] }, chatId) (false when unknown).
• getFeatures() now advertises read-receipts.

Why in-memory (not persisted like 2b)

Baileys re-syncs the full contact + chat list via messaging-history.set on every connect, so this is current-state data, not a durable append-log — an in-memory store rebuilt on connect is the right fit and avoids new tables/migrations/repos. It survives transient reconnects (instance state) and repopulates after a process restart on the next connect. No new data-at-rest.

Out of scope — gated (501)

• getChatHistory — Baileys has no on-demand history API (unlike wwjs's live fetchMessages); serving from the bounded message store would mislead.
• getMessageReactions, labels/channels/status/catalog — parity with the whatsapp-web.js engine (which also stubs them); likely permanent.

These are now the only gated methods — the Baileys engine is feature-complete vs the neutral interface.

Best-effort notes

Contact.isMyContact = true / isBlocked = false (blocklist not tracked); getChats lastMessage/timestamp populate from live messages (fallback conversationTimestamp). Documented.

Testing

• 627 unit + 6 e2e green; backend lint 0 / build clean; dashboard build clean / lint 0 errors.
• New coverage: BaileysSessionStore (full+partial merge, newest-message-wins, neutral mapping, lid resolution); adapter (events populate → reads return mapped neutral; messaging-history.set incl. lid; sendSeen/deleteChat call args + false-when-unknown; getChatHistory still 501; ensureReady guards); e2e feature list synced to 11. Fixed a FakeSock listener leak (MaxListenersExceededWarning) by resetting the emitter per describe.