Email-proposal review over Matrix + a bot role (v0.1.0:89)

The email-capture "proposed grid notes" gain two review surfaces:

1. Inline source email — each proposed-note card on the Email Capture page
   gets a "View email" toggle that lazily fetches the existing
   GET /api/email/detail and shows from/to/cc/date/subject + scrollable body,
   so a reviewer can judge the note against the email it was drafted from.

2. CRM->Matrix review bridge — the CRM (box, stdlib, no matrix-nio) can't post
   to Matrix, so the intake bot (Spark) PULLS: GET /api/intake/email-proposals
   returns to_post/open/to_close work-lists; the bot posts a review card
   (metadata + snippet + draft note) to a dedicated review room
   (MATRIX_EMAIL_REVIEW_ROOM) and relays in-thread yes / no / NL-edit
   (POST .../{id}/decide, note revised via local Qwen). Decisions sync both
   ways: web decide -> bot announces + closes the thread; Matrix decide -> the
   web panel's ~25s poll clears the card. State lives CRM-side in the new
   email_proposal_matrix side row (email-integration migration 0003, additive
   + idempotent CREATE TABLE IF NOT EXISTS), so it survives a bot restart.

Adds a 'bot' role (authenticated, never admin; require_bot_or_admin) to gate
the email-proposal endpoints rather than handing the bot full admin — the
principled base for the coming agentic capabilities. Role controls reach;
the draft->approve gate still controls autonomy (a human approves every write).

Deploy split: endpoints + migration + role + frontend ship in the s9pk; the
bot poll loop + review-room handling ship on the Spark. The bot's CRM user
must be flipped member->bot and joined to the review room (one-time).

Tests: backend/test_email_proposal_matrix.py + matrix_intake/test_email_proposals.py
(30/30 suite green, render-smoke green, migration verified twice on a DB copy).

.env.example

@@ -57,6 +57,13 @@ MATRIX_USER=@intake-bot:<homeserver>
 MATRIX_ACCESS_TOKEN=
 MATRIX_DEVICE_ID=ten31-intake-bot
 MATRIX_INTAKE_ROOM=!<roomid>:<homeserver>
+# Dedicated room for reviewing CRM-drafted email-activity proposals (the proposed grid notes the
+# Email Capture panel shows). The bot posts a review card per pending proposal here and relays the
+# in-thread yes/no/edit back to the CRM, in sync with the web panel. Separate from the intake room
+# so high-volume email proposals don't drown the conversational intake. Leave empty to disable the
+# whole email-review poll loop. The bot must be a member of this room. Needs the server side in the
+# s9pk (≥ v0.1.0:89) and the bot's CRM user set to role 'bot' (see docs/guides/matrix-intake.md).
+MATRIX_EMAIL_REVIEW_ROOM=!<roomid>:<homeserver>
 # CRM write-back: the bot logs in as a DEDICATED service user (admin-created CRM user;
 # the CRM has no service-key path, so it uses normal Bearer-JWT auth).
 CRM_API_BASE=http://127.0.0.1:8080