Email-signature → contact enrichment

**From the cross-app automation audit (`~/ppp2/AUTOMATION-AUDIT.md`). Score 19/25, effort S. Ports to all 3 CRMs (artcrm / engcrm / general-crm).**

## The idea
Parse the signature block of inbound emails (the follow-up agent already reads the inbox) and enrich the contact — phone, title, role, company, address — from data the contact literally handed you.

## Why it scored 19
Very clean mechanical split (Mech 5) and high reuse — the inbox read already happens in the follow-up agent; this just mines the signature.

## Decisions to make
- **Propose vs auto-update** — recommend *propose* enrichments for approval, especially when overwriting existing values.
- **Conflict handling** — signature phone ≠ on-file phone: overwrite, keep both, or flag?
- **Which fields** — phone/title/company/address — any you don't want auto-touched?
- **Port scope** — all 3 CRMs now, or just the active ones? (general-crm is currently dormant/broken.)

## Reuse
The follow-up agent's inbox read; a signature parser + the existing `update_contact_details` path.

Start with the follow-up agent's inbox-read path and the existing update_contact_details path; the audit is documented in ~/ppp2/AUTOMATION-AUDIT.md. Before implementation, resolve whether enrichments are proposed or automatic, how conflicts are handled, which fields are eligible, and whether all three CRMs are in scope. Done means signature data is parsed and enrichment follows the agreed approval and conflict behavior.

Written by the indexing model from the issue text.