docs(email): record send API evidence

docs/work-programmes/decisions.md

@@ -419,3 +419,13 @@
 - **Consequences:** existing connections show read-only until explicit reconnect consent. Gmail supports its provider thread ID; Graph currently sends a new message and does not claim reply-thread semantics. The later API must reserve the ledger before calling either adapter and surface uncertain state for manual reconciliation.
 - **User approval required:** No; this repository-side programme requirement used fake transports only. Real account consent/send still requires an explicitly authorized synthetic provider account.
 - **Reversible:** Yes. Revert `e9937ac` to stop requesting/using send permission. Already granted provider permission is managed by the provider/user connection and is not automatically revoked by a code rollback.
+
+## DEC-043 — Send admission reserves before delivery and never retries ambiguity
+
+- **Date:** 2026-08-10
+- **Decision:** Admit provider delivery only through an authenticated, user-rate-limited route that requires an owned job, explicit confirmation and a canonical client UUID. Reserve and begin the content-free ledger before provider I/O; persist sent correspondence, a content-free job event and the sent state in one local transaction. Return existing sent results but reject every other duplicate, especially uncertain attempts.
+- **Reason/evidence:** provider acceptance cannot share the database transaction. Owner-scoped SQLite tests prove malformed, unconfirmed and cross-tenant requests do not reserve or send; duplicate, rejected and interrupted attempts call the fake provider at most once. Canonical UUID formatting closes a simple deduplication bypass.
+- **Alternatives considered:** call the provider before reserving; retry timeouts; rely on a disabled button; store message content in the ledger/event; use legacy application SMTP; mark local persistence failure as sent. These can duplicate delivery, lose audit state, expose content or bypass connected-provider consent.
+- **Consequences:** a successful provider call with failed local persistence is intentionally uncertain and requires manual reconciliation. A process stop after admission can leave a `sending` row; a later repository increment must age it into an explicit uncertain/manual-review state without redelivery. Existing read-only connections cannot send until re-consented.
+- **User approval required:** No; MAIL-001 explicitly authorizes local implementation and fake verification. Real provider consent/send remains gated.
+- **Reversible:** Yes. Disable admission/UI, then revert `123fc55`. No schema rollback is needed for this route-only increment.