feat(mail): enforce owned profile self-service

docs/MAIL_HANDBOOK.md

@@ -142,24 +142,38 @@ The supplied templates are:
 
 - **Mail profile user:** read/use/test approved profiles and read permitted
   mailboxes without reading secrets.
+- **Mail profile self-service user:** additionally create, edit, deactivate,
+  and manage credentials only for the current account's own user-scoped
+  profiles, subject to the effective Mail policy.
 - **Mail profile administrator:** additionally create/update profiles and
-  create/replace encrypted credentials.
+  create/replace encrypted credentials across tenant-owned scopes.
 
 The specific permissions are `mail:profile:read`, `mail:profile:use`,
-`mail:profile:test`, `mail:mailbox:read`, `mail:profile:write`, and
-`mail:secret:manage`. System-scoped definitions use the corresponding system
-settings authority. Keep secret management separate when an institution wants
-profile metadata administrators not to know or replace credentials.
+`mail:profile:test`, `mail:mailbox:read`, `mail:profile:write_own`,
+`mail:secret:manage_own`, `mail:profile:write`, and `mail:secret:manage`.
+The `_own` permissions are enforced against the authenticated membership id and
+never authorize a tenant, group, campaign, system, or another user's profile.
+They also do not authorize profile-policy changes. System-scoped definitions
+use the corresponding system settings authority. Keep secret management
+separate when an institution wants profile metadata administrators not to know
+or replace credentials.
+
+That separation is fail-closed for transport rebinding: changing an SMTP or
+IMAP host, port, or security mode while the profile retains a stored password
+requires the matching secret-management permission. A credential-free profile
+can be deactivated with profile-write authority alone; deactivation that
+scrubs a stored password also requires secret-management authority and records
+the deletion in the audit log.
 
 ### Create or change a profile
 
 The configured Help Center exposes **Create a custom Mail profile** only when
-the current actor has profile-write authority and the effective user-scope
-policy permits user profiles. It states the active SMTP/IMAP hostname
+the current actor has broad or self-service profile-write authority and the
+effective user-scope policy permits user profiles. It states the active SMTP/IMAP hostname
 allow-list groups and deny rules, plus the actor's separate credential, test,
 use, and approval requirements. The Settings task creates in the current
-account's user scope; `mail:profile:write` itself remains broad profile
-administration authority, not an API-enforced self-only permission.
+account's user scope. Grant `mail:profile:write_own` for self-service;
+`mail:profile:write` remains broad profile administration authority.
 
 1. Choose the narrowest suitable scope and a stable, descriptive name/slug.
 2. Configure SMTP, optional IMAP, TLS mode, account identity, Sent-folder