fix(whatsapp-gateway): self-chat E2EE, agent UUID resolution, auto-connect

[Shuichi-code]

Summary

Fixes multiple issues preventing the WhatsApp Web gateway from properly receiving and replying to messages through OpenFang:

• Upgrade Baileys v6 → v7.0.0-rc.9 — Fixes "Waiting for this message" E2EE decryption errors when using self-chat (Notes to Self). Baileys v6 lacks proper multi-device self-chat E2EE support.
• Add getMessage callback with in-memory message store — Required by Baileys v7 for E2EE decryption of self-sent messages on linked devices.
• Resolve agent name → UUID at startup — Calls GET /api/agents to map human-readable agent names (e.g. "assistant") to UUIDs, fixing "Invalid agent ID" errors from the OpenFang API.
• Auto-connect on startup — If auth_store/creds.json exists from a previous session, automatically reconnects to WhatsApp without requiring POST /login/start. Essential since the OpenFang daemon spawns the gateway as a child process.
• Handle WhatsApp LID JIDs — Converts privacy-preserving @lid JIDs to @s.whatsapp.net for proper message delivery.
• Support self-chat (Notes to Self) — Accepts fromMe messages and routes replies to the account owner's JID instead of the LID.
• Quote original message in replies — Provides E2EE context for message decryption on linked devices.
• File-based logging — Writes to gateway.log since the OpenFang daemon captures stdout, making debugging difficult.

Test plan

• Fresh QR code scan connects successfully with Baileys v7
• Auto-reconnects on startup when auth_store/creds.json exists
• Agent name resolves to UUID via /api/agents endpoint
• Incoming messages from other users are forwarded to OpenFang and replies sent back
• Self-chat messages (Notes to Self) are forwarded and replied to without "Waiting for this message" errors
• Messages from LID JIDs are properly converted and delivered
• gateway.log is written with timestamped entries