docs(leadchat): add Phase 1b smoke-test checklist + LeadMail regression warning

Captures the test sequence to run on staging when resuming this work,
including the critical regression check that the LeadmailDelivery payload
patch hasn't broken existing transactional emails.

LEADCHAT.md

@@ -68,3 +68,41 @@ Strings/files that the brand script rewrites away from "Chatwoot". Extend this l
 - Conventional Commits (`type(scope): subject`)
 - No Claude attribution in commits or PR bodies
 - Update this file as each customization lands, not as a final pass
+
+## Phase 1b smoke-test checklist (run after staging deploy)
+
+Pre-req on M365 admin:
+- Delegate user (e.g. Niklas) has `Send As` + `Full Access` on the test shared mailbox.
+- For `imap_smtp`: enable both **Authenticated SMTP** and **IMAP** in Active users → user → Mail → Manage email apps. Confirm no Conditional Access policy blocks them.
+- For `imap_leadmail`: enable **IMAP** only.
+- For `graph_full`: assign a Microsoft 365 license to the shared mailbox itself. (Skip this transport if you don't want to license shared mailboxes.)
+
+Deployment:
+1. `cd /home/ploi/chat.leadm.app && git pull origin leadchat`
+2. Free RAM (stop Sidekiq + Site + gitea via Ploi/systemctl), then:
+   `NODE_OPTIONS="--max-old-space-size=3072" RAILS_ENV=production bundle exec rake assets:precompile`
+3. Restart Sidekiq, Site, gitea.
+
+Regression check (do FIRST, before testing the new feature):
+- Trigger any transactional email that goes through LeadMail (e.g. invite a new user, or trigger a password-reset email). Confirm it still arrives normally. The LeadmailDelivery patch added `in_reply_to`, `references`, and `message_id` to the API payload — if your LeadMail server rejects unknown fields, this could regress all transactional email. If transactional emails fail, revert just the LeadmailDelivery part of commit `3c93714f2` until LeadMail server tolerates extra fields.
+
+Smoke test `imap_smtp` (highest priority):
+1. Add Inbox → Email → Microsoft Shared Inbox → enter shared UPN → pick "SMTP + IMAP" transport → Connect.
+2. OAuth consent screen should list `IMAP.AccessAsUser.All` and `SMTP.Send` (Outlook scopes).
+3. After redirect: assert `Channel::Email` row has `provider='microsoft_shared'`, `imap_login=<shared upn>`, `provider_config['transport']='imap_smtp'`.
+4. External email → shared mailbox → conversation appears in LeadChat within ~1 minute.
+5. Reply from LeadChat → recipient receives email From: shared mailbox address; threading headers preserved.
+6. Watch `tail -f /home/ploi/chat.leadm.app/log/production.log | grep -iE 'microsoft_shared|imap'` for errors.
+
+Smoke test `imap_leadmail`:
+1. Same as above but pick "LeadMail send" transport.
+2. After OAuth, scopes should be `IMAP.AccessAsUser.All` only.
+3. Reply from LeadChat → verify in LeadMail's outbox/log that the email went via LeadMail (not M365 SMTP).
+4. Verify From: header is the shared mailbox; verify DKIM passes for `leadmagnet.fi` (Gmail's "Show original" view shows DKIM=PASS).
+5. External replies to your LeadMail-sent message → assert it threads back into the same Chatwoot conversation. If threading fails, the LeadMail server isn't honoring the new `in_reply_to`/`references` payload fields — needs a server-side fix.
+
+`graph_full` (only if you license a mailbox to test):
+1. Same as above, "Microsoft Graph" transport.
+2. Send works; receive doesn't until Phase 2 webhook subscription is built.
+
+Phase 2 + Phase 3 deferred — only needed if `graph_full` becomes a real use case (Phase 2) or polish UX surfaces issues with re-auth / cleanup (Phase 3).