email extraction: plugin side built, platform untouched

docs/email-plugin-extraction.md

@@ -3,7 +3,10 @@
 Started 2026-08-17. The runbook is `plugins/EXTRACTING-A-PLUGIN.md` and it is the authority; this file only
 records what is specific to email — the boundary, the decisions taken, and what they cost.
 
-**Status: mapped, decisions taken, not yet moved.**
+**Status: the plugin side is built and typechecks. The platform has NOT been touched.**
+
+Everything so far is additive, inside `plugins/email/` — which is gitignored, so the platform tree is
+unchanged and email is exactly as switched-off as it was. Nothing is broken and nothing needs reverting.
 
 The owner asked for a full extraction with no interim step ("no temporary steps"), and was explicit that
 speed is not the constraint. Email is therefore NOT being switched back on in place first, even though that
@@ -96,7 +99,17 @@ this extraction on new platform work).
 else, so this is the shape available; the alternative is a second plugin route. **User-visible change:** you
 will add and remove mail accounts from `/email`, not from `/settings/integrations`.
 
-### 3. Encrypt the credentials — TAKEN
+### 3. Encrypt the credentials — REVERSED, deferred to the plugin
+
+Originally taken on the reasoning that the table has never held a row here, so encryption was free. That
+reasoning only covers THIS machine — another install may have rows from before 2026-08-13, and a format
+change would strand them.
+
+The stronger argument is about verification: a pure move is checkable, because any first-install failure is
+the move. A move plus a data-format change gives a failure two causes, on a feature nothing has exercised in
+four days. Encryption is now the first item in the plugin's own README.
+
+### 3b. What the original decision said — TAKEN, then reversed
 
 `email_accounts.credentials` is jsonb holding an IMAP app password in the clear. It is encrypted through
 `officerdb/crypto` under its own `email` secret-store purpose as part of the move.