docs(email): record hub unlink evidence

docs/work-programmes/decisions.md

@@ -499,3 +499,13 @@
 - **Consequences:** both application surfaces now generate the same optional contextual searches without automatic linking. Provider category mutations remain explicit remaining work that requires a separately reviewed scope/re-consent design.
 - **User approval required:** No; this is a local shared-view correction inside active MAIL-001 and invokes no provider.
 - **Reversible:** Yes. Revert the context-prop changes and test; stored data, scopes and provider grants are unchanged.
+
+## DEC-051 — Unlink the app relationship, never the provider copy
+
+- **Date:** 2026-08-10
+- **Decision:** Expose confirmed Gmail unlink in the canonical hub through the existing owner-scoped unlink endpoint. Label the data effect explicitly and show no equivalent action for providers without a supported link domain.
+- **Reason/evidence:** unlink already existed in the per-job component but not the hub, creating inconsistent copies of the same workflow. The endpoint removes imported JobTracker correspondence for the owned job and returns the thread to review; it does not call Gmail deletion. UI confirmation and real-SQLite two-user tests pass.
+- **Alternatives considered:** delete provider mail; implement a duplicate endpoint; show disabled Outlook/IMAP actions; remove unlink from the per-job view. These broaden authority, duplicate behavior, mislead users or regress a supported workflow.
+- **Consequences:** a thread can be reconsidered in recruitment review after unlink. Imported JobTracker copies are removed only after confirmation, while the mailbox remains untouched. Relink/move stays on the existing per-job management surface for now.
+- **User approval required:** No; this is local implementation of the approved MAIL-001 unlink workflow and uses only mocked/synthetic data.
+- **Reversible:** Yes. Revert `1dabbeb`; the endpoint and per-job unlink remain available, with no schema/provider grant change.