chore: sync GovOPlaN module split state

docs/MAIL_PROTOCOL_ROADMAP.md

@@ -0,0 +1,50 @@
+# Mail Protocol Roadmap
+
+GovOPlaN Mail currently focuses on SMTP sending and IMAP mailbox access. POP3
+and JMAP are deferred until the IMAP mailbox MVP is stable.
+
+## Current Baseline
+
+- SMTP is the send protocol.
+- IMAP is the read/append protocol.
+- Mail profile policy, encrypted credentials, mailbox folder parsing, test
+  buttons, and read-only mailbox UI are built around SMTP and IMAP.
+
+This baseline matches the first production use case: send campaign mail, append
+sent copies when configured, and inspect mailboxes read-only.
+
+## JMAP
+
+JMAP is the preferred future sync/search protocol where target mail servers
+support it.
+
+Reasons:
+
+- HTTP/JSON transport fits the platform API style better than stateful IMAP
+- efficient mailbox state sync and changes endpoints
+- modern search and thread models
+- better fit for browser-facing mailbox UX through a server proxy
+
+JMAP should be added only after:
+
+- the IMAP mailbox MVP has stable folder/message pagination behavior
+- mail profile policy can express protocol-specific availability
+- mailbox UI can handle protocol-neutral folder/message DTOs
+- test infrastructure includes at least one reliable JMAP server target
+
+## POP3
+
+POP3 should remain legacy-only.
+
+Add it only when a concrete deployment requires mailbox download from a server
+that cannot offer IMAP or JMAP. POP3 is a poor fit for the normal GovOPlaN
+mailbox UX because it has limited folder, sync, and server-side state semantics.
+
+If implemented, POP3 should be scoped to explicit download/import workflows, not
+general mailbox browsing.
+
+## Decision
+
+Do not add POP3 or JMAP now. Stabilize SMTP/IMAP first, design protocol-neutral
+mailbox DTOs, then prefer JMAP for modern servers and reserve POP3 for explicit
+legacy download requirements.