v0.4.5

A Baileys engine quality-and-correctness release, plus a chat-history enhancement. Identity: inbound
Baileys message ids are now engine-neutral (@c.us, matching whatsapp-web.js), the dashboard Chats list
shows saved/contact names instead of raw JIDs, and @lid (privacy-id) senders resolve to a phone number.
Messaging: an opt-in deep=true mode lets the live chat-history endpoint reach up to 2000 messages
back on whatsapp-web.js, and Baileys can now send captions with document messages. One behavior change
to note: message.received / revoked / reaction webhook and WebSocket payloads from a Baileys
session now carry @c.us ids where they previously carried @s.whatsapp.net (or a resolved @lid) — a
consumer that stored or compared the old ids will see the new value.

Added

• Opt-in deep chat history (deep=true). GET /sessions/:id/messages/:chatId/history was capped at
  100 messages per request — OpenWA's own bound, not a WhatsApp limit, since whatsapp-web.js can load
  earlier messages on demand. A new deep=true query raises the ceiling to 2000 so callers can reach
  weeks/months back. Deep mode is metadata-only (it ignores includeMedia, since base64 for up to 2000
  messages would be an enormous payload). The default path is unchanged (default 50, max 100). The Baileys
  engine has no history sync, so the endpoint still returns 501 there regardless of deep. (#347)

Fixed

• Baileys engine: the Chats list now shows saved/contact names instead of a raw number or @lid. When
  Baileys supplied a chat without a title, the dashboard Chats list fell back to the raw JID user-part (a
  bare number, or a privacy-id for @lid contacts). The session store now resolves a best-known display
  name from the synced contacts — preferring the saved name, then the business verifiedName, then the
  pushName (notify) — and for a @lid chat it also looks up the contact behind the resolved phone. The
  raw user-part remains the last resort, so a name is shown whenever WhatsApp has delivered one. No API
  shape change (ChatSummary.name is simply better populated). (#369)

• Baileys engine: @lid senders now resolve to a phone number. senderPhone and
  GET /sessions/:id/contacts/:id/phone always returned null for privacy-id (@lid) contacts on
  Baileys: the resolver only consulted mappings from contacts.* / messaging-history.set, which don't
  fire for a fresh inbound @lid sender, and baileys@6.7.23 has no getPNForLID lookup. The adapter now
  learns the lid -> phone pair that Baileys attaches to the inbound message key (senderPn /
  participantPn), so the sender of an incoming message resolves to its number and later contact lookups
  succeed. Still best-effort by design — a number is only revealed once WhatsApp delivers the mapping
  (e.g. an inbound message from that contact). (#362)

• Baileys engine: inbound message ids are now engine-neutral (@c.us). The Baileys adapter emitted
  its native <phone>@s.whatsapp.net / <lid>@lid ids in message payloads (from / to / chatId /
  author, plus revoked and reaction events), while the whatsapp-web.js engine and the rest of the
  system use the <phone>@c.us convention - so the same contact was addressed under a different id
  depending on the engine, and @lid (privacy-id) contacts could not be resolved to a phone. Baileys
  now canonicalizes these to the neutral dialect (resolving a @lid to its phone when the mapping is
  known, keeping it as @lid otherwise), matching whatsapp-web.js. Group participant and owner ids are
  canonicalized through the same path, so admin/controller recognition (e.g. the translation plugin)
  keeps working. Consumer-visible: message.received / revoked / reaction webhook and WebSocket
  payloads from a Baileys session now carry @c.us ids where they previously carried
  @s.whatsapp.net (or a resolved @lid); a consumer that stored or compared the old ids will see the
  new value. Outbound sending and contact/chat list ids are unchanged for now.

• Baileys engine: documents can now be sent with a caption. sendDocumentMessage dropped
  media.caption on the Baileys engine, while whatsapp-web.js already forwarded it. Baileys now sends the
  caption too (parity across engines); the document stores the caption as its message body, falling back
  to the filename when absent. (#363)