docs: document the Campaign-to-Mail delivery boundary

examples/README.md

@@ -15,7 +15,7 @@ campaign schema and do not require production data.
 | `recipient-attachment-rules` | core, access, campaigns; optional files | Match recipient-specific attachment rules and verify per-recipient evidence. |
 | `zip-protected` | core, access, campaigns | Build password-protected AES ZIP output and verify password-source metadata. |
 | `mail-profile-send` | core, access, campaigns, mail | Select a reusable mail profile and send through the GreenMail test bed. |
-| `inline-mail-settings` | core, access, campaigns, mail | Use campaign-local SMTP/IMAP settings only when policy allows it. |
+| `legacy-inline-mail-rejected` | core, access, campaigns, mail | Confirm legacy campaign-local SMTP/IMAP data fails closed and requires explicit profile migration. |
 | `warnings-review` | core, access, campaigns | Require explicit review before queueing jobs with warnings. |
 | `blocked-send` | core, access, campaigns | Confirm blocked recipients or missing attachments cannot be queued. |
 | `mock-delivery` | core, access, campaigns, mail with dev capability | Capture messages in the development mailbox. |
@@ -26,8 +26,8 @@ campaign schema and do not require production data.
 - Do not commit real recipients, mail credentials, or production attachment
   names.
 - Keep attachments deterministic and small.
-- Store secrets as placeholders, saved-credential references, or local `.env`
-  values consumed by the test bed.
+- Store transport secrets only in encrypted Mail profiles or local `.env`
+  values consumed directly by the test bed, never in campaign JSON.
 - Declare optional module requirements in fixture metadata.
 - Fixtures must not import files or mail modules directly; optional behavior is
   discovered through core module metadata and capabilities.