v0.8.0

Added

• Integration Fabric: provision and connect external services to WhatsApp sessions. ADMIN operators can mint per-plugin instances — one per external account — through a provisioning API and a new dashboard Instances tab, each with its own HMAC-verified inbound webhook endpoint, operator-set secret, and per-session configuration. Integration plugins gain the capabilities needed to build a two-way bridge: ctx.registerWebhook to receive that inbound traffic, ctx.mappings to correlate a WhatsApp chat with an external conversation, a session-and-chat-scoped handover gate so a chat handed to a human is withheld from the owning plugin while the bot and other plugins still receive it, and net.allowConfigHosts to permit an outbound request to a host drawn from the instance's own configuration. This is the foundation for provider adapters. (#568, #570, #571, #575, #585, #587, #588, #589)

Fixed

• Replying to and forwarding to a LID-migrated contact no longer fail with HTTP 500 on the whatsapp-web.js engine. These paths sent to the phone id (@c.us) like the original send bug (#573), so a contact WhatsApp had migrated to @lid rejected them with No LID for user. They now resolve the recipient the same way as a normal send (including the self-heal retry), and a forward reads back its delivered id from the resolved chat so delivery status still reconciles. (#583)
• The typing/presence endpoint no longer returns HTTP 500 on the Baileys engine when a presence update fails. Presence is best-effort; a failure (e.g. No LID for user for a migrated contact) is now caught and logged at WARN and the request succeeds, matching the whatsapp-web.js engine. This also covers the presence agent tool. (#583)
• Chat history for a LID-migrated contact is no longer split across two entries on the whatsapp-web.js engine. The engine now records the phone ↔ lid mapping it learns (when resolving a send, and when resolving an inbound @lid sender's number), so the messages API bridges a contact's @c.us and @lid rows into one conversation — previously only the Baileys engine populated this mapping. (#583)
• The dashboard chat list no longer refetches on every message sent to a LID-migrated contact. The outgoing echo can arrive addressed as @lid while the open chat is @c.us; the sent message is already shown via the send response, so the sidebar no longer triggers a full reload for an outgoing echo with no matching chat. (#583)