Release v0.1.0-preview.28: transactional account email

Reviewed source export adds verified TLS mail, encrypted outbox, mailbox verification and password reset protocols. Preserve public ancestry; omit local development history and operational queue. Consumer deployment and inbox delivery proof remain separate.

docs/THREAT_MODEL.md

@@ -59,6 +59,23 @@ configured reverse proxy, authorize application routes automatically, encrypt a
 compromised host, or decide how long an operator may lawfully retain personal
 request evidence.
 
+Optional account mail treats email links as bearer secrets, not sessions or MFA.
+`authmail` binds random single-use digests to account identity, purpose, current
+credential and expiry. Address changes additionally require current password,
+session and both mailboxes. Reset requires an already verified current mailbox;
+success creates no login and removes no enrolled factor. The SQLite adapter
+atomically rechecks authority, revokes sessions/grants and queues notices with
+the audit. Existing ownership and financial records are not reassigned.
+
+SMTP authenticates only after verified TLS with no plaintext fallback. Encrypted
+outbox payloads require an application-owned key, which may itself be wrapped in
+SQLite only when its external wrapping key is kept separately. Compromise of
+the sender, recipient mailbox or application host remains a threat. SMTP DATA
+acceptance is not inbox delivery and crash retries are not exactly once. Forms,
+CSRF/origin enforcement, fragment-to-POST handling, IP/concurrency limits and
+non-enumerating responses remain explicit consumer responsibilities; see the
+[integration boundaries](../authmail/README.md).
+
 Applications must pass the authenticated user and requested resource hierarchy
 to `access.Authorize`; possessing a platform-level `auth` role does not bypass
 that decision. Team membership is resolved by the repository rather than